help me

**Marius Bernklev** · Jul 18 '05, 04:19 PM

Re: help me

chrispatton@gma il.com (Chris Patton) writes:
[color=blue]
> Hey everybody. I am writing a program that requires the user to make
> the name for variables inside the program. For example:
>[color=green][color=darkred]
>>>> exec raw_input()+' = 34'[/color][/color]
>
> However, I don't want to have to use the "exec" statement. Thanks for
> any help![/color]

Are you sure you don't want to use a plain dict for this? And if so, why?

--
Marius Bernklev
<URL: http://www.ping.uio.no/~mariube/ >

**dataangel** · Jul 18 '05, 04:20 PM

Re: help me

Marius Bernklev wrote:
[color=blue]
>chrispatton@gm ail.com (Chris Patton) writes:
>
>
>[color=green]
>>Hey everybody. I am writing a program that requires the user to make
>>the name for variables inside the program. For example:
>>
>>
>>[color=darkred]
>>>>>exec raw_input()+' = 34'
>>>>>
>>>>>[/color]
>>However, I don't want to have to use the "exec" statement. Thanks for
>>any help!
>>
>>[/color]
>
>Are you sure you don't want to use a plain dict for this? And if so, why?
>
>
>
>[/color]
Why don't you want to use exec? Just curious. That's the normal way to
get a string to python code as far as I know.

**Richard Blackwood** · Jul 18 '05, 04:20 PM

Re: help me

There is always eval(). His example could be done with out either though.

<SNIP>
[color=blue][color=green]
>>
>>[color=darkred]
>>> Hey everybody. I am writing a program that requires the user to make
>>> the name for variables inside the program. For example:
>>>
>>>
>>>
>>>>>> exec raw_input()+' = 34'
>>>>>>
>>>>>
>>> However, I don't want to have to use the "exec" statement. Thanks for
>>> any help!
>>>[/color]
>>
>>
>> Are you sure you don't want to use a plain dict for this? And if so,
>> why?
>>
>>
>>
>>[/color]
> Why don't you want to use exec? Just curious. That's the normal way to
> get a string to python code as far as I know.
>[/color]

**Peter L Hansen** · Jul 18 '05, 04:20 PM

Re: help me

dataangel wrote:[color=blue]
> Marius Bernklev wrote:[color=green]
>> chrispatton@gma il.com (Chris Patton) writes:[color=darkred]
>>> Hey everybody. I am writing a program that requires the user to make
>>> the name for variables inside the program. For example:
>>>>>> exec raw_input()+' = 34'
>>>
>>> However, I don't want to have to use the "exec" statement. Thanks for
>>> any help![/color]
>> Are you sure you don't want to use a plain dict for this? And if so,
>> why?
>>[/color]
> Why don't you want to use exec? Just curious. That's the normal way to
> get a string to python code as far as I know.[/color]

No, it's not the normal way, it's the crude and insecure way.

The normal way is to use the string as a key to a dictionary,
perhaps locals() or globals(), as Marius appears to be
suggesting.

Like regular expressions, in the hands of a beginner exec
and eval() lead to code that is one or more of dangerous,
unreadable, unmaintainable, awkward, or just plain sloppy.

-Peter

**Richard Blackwood** · Jul 18 '05, 04:20 PM

Re: help me

<SNIP>
[color=blue]
>
> Like regular expressions, in the hands of a beginner exec
> and eval() lead to code that is one or more of dangerous,
> unreadable, unmaintainable, awkward, or just plain sloppy.
>
> -Peter[/color]

He's got to learn somehow! LOL

**Andrew Dalke** · Jul 18 '05, 04:20 PM

Re: help me

dataangel:[color=blue]
> Why don't you want to use exec? Just curious. That's the normal way to
> get a string to python code as far as I know.[/color]

That's not the normal way. Where did you get that idea?
[color=blue][color=green][color=darkred]
>>> exec raw_input("ente r name: ")+' = 34'[/color][/color][/color]
enter name: import os; os.system("pwd && echo rm -rf /delete/any/file"); c
/Users/dalke/src
rm -rf /delete/any/file[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

In other words, without full vetting of the input it's
a hugh security hole.

If you want to set a global variable (why??) then use
the globals() dictionary.
[color=blue][color=green][color=darkred]
>>> spam[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'spam' is not defined[color=blue][color=green][color=darkred]
>>> globals()[raw_input("ente r name: ")] = 34[/color][/color][/color]
enter name: spam[color=blue][color=green][color=darkred]
>>> spam[/color][/color][/color]
34[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

More than likely you should put the data into a
dictionary of its own. Otherwise, what happens
if someone assigns to the variable 'raw_input'?
[color=blue][color=green][color=darkred]
>>> globals()[raw_input("ente r name: ")] = 34[/color][/color][/color]
enter name: raw_input[color=blue][color=green][color=darkred]
>>> globals()[raw_input("ente r name: ")] = 34[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'int' object is not callable[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Andrew
dalke@dalkescie ntific.com

**Richard Blackwood** · Jul 18 '05, 04:20 PM

Re: help me

<SNIP>
[color=blue]
>
>[color=green][color=darkred]
> >>> globals()[raw_input("ente r name: ")] = 34[/color][/color]
> enter name: raw_input[color=green][color=darkred]
> >>> globals()[raw_input("ente r name: ")] = 34[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: 'int' object is not callable[color=green][color=darkred]
> >>>[/color][/color]
>
> Andrew
> dalke@dalkescie ntific.com[/color]

exec and eval is dangerous stuff for the inexperienced. Dictionary is
an excellent idea Andrew. However, if what he wants to do is as simple
as the example he gave, he doesn't even need a dictionary.

**dataangel** · Jul 18 '05, 04:20 PM

Re: help me

Richard Blackwood wrote:
[color=blue]
> <SNIP>
>[color=green]
>>
>> Like regular expressions, in the hands of a beginner exec
>> and eval() lead to code that is one or more of dangerous,
>> unreadable, unmaintainable, awkward, or just plain sloppy.
>>
>> -Peter[/color]
>
>
> He's got to learn somehow! LOL[/color]

Well, I remember looking up the exec keyword and it saying executes a
string. Thus, it seemed like the normal way to execute a string, lol.

Using globals() makes sense, but using locals() doesn't because it won't
have the desired effect. locals() returns a _copy_, globals() is an
actual reference.

**Andrew Dalke** · Jul 18 '05, 04:20 PM

Re: help me

dataangel wrote:[color=blue]
> Well, I remember looking up the exec keyword and it saying executes a
> string. Thus, it seemed like the normal way to execute a string, lol.[/color]

But why did that seem like it should be the normal way
to do variable assignment to global?

BTW, locals() doesn't work like you want in part because
that prevents a performance optimization where local
variable lookups are done in O(1) time as an offset
into a fixed size table. I suppose it would be possible
to have locals() be able to manipulate that table behind
the scenes, but then that would be complicated and complex.

Andrew
dalke@dalkescie ntific.com

**dataangel** · Jul 18 '05, 04:20 PM

Re: help me

Richard Blackwood wrote:
[color=blue]
> <SNIP>
>[color=green]
>>
>>[color=darkred]
>> >>> globals()[raw_input("ente r name: ")] = 34[/color]
>> enter name: raw_input[color=darkred]
>> >>> globals()[raw_input("ente r name: ")] = 34[/color]
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>> TypeError: 'int' object is not callable[color=darkred]
>> >>>[/color]
>>
>> Andrew
>> dalke@dalkescie ntific.com[/color]
>
>
> exec and eval is dangerous stuff for the inexperienced. Dictionary is
> an excellent idea Andrew. However, if what he wants to do is as
> simple as the example he gave, he doesn't even need a dictionary.
>
>[/color]
Alright, you say he doesn't need a dictionary, and the other guy says he
doesn't actually need eval. What is this mysterious non-exec, non-eval,
non-globals(), non-dictionary solution? ;)

**Richard Blackwood** · Jul 18 '05, 04:20 PM

Re: help me

<SNIP>
[color=blue][color=green]
>>[/color]
> Alright, you say he doesn't need a dictionary, and the other guy says
> he doesn't actually need eval. What is this mysterious non-exec,
> non-eval, non-globals(), non-dictionary solution? ;)
>[/color]
Nevermind. My bad. I misread your post. Go with the globals()
function, it will save you some headaches vs. eval() and exec. On the
other hand, you could also use eval w/ the globals dictionary. I don't
think that has any problems but Andrew can correct me on this one.

**Andrew Dalke** · Jul 18 '05, 04:20 PM

Re: help me

Richard Blackwood wrote:[color=blue]
> On the
> other hand, you could also use eval w/ the globals dictionary. I don't
> think that has any problems but Andrew can correct me on this one.[/color]

I gave an example of assigning to 'raw_input'. Most
likely not something you want people to change.

Andrew
dalke@dalkescie ntific.com

**Richard Blackwood** · Jul 18 '05, 04:20 PM

Re: help me

<SNIP>
[color=blue]
>
> I gave an example of assigning to 'raw_input'. Most
> likely not something you want people to change.
>
> Andrew
> dalke@dalkescie ntific.com[/color]

Indeed.

**Alex Martelli** · Jul 18 '05, 04:21 PM

Re: help me

Andrew Dalke <adalke@mindspr ing.com> wrote:
[color=blue]
> dataangel wrote:[color=green]
> > Well, I remember looking up the exec keyword and it saying executes a
> > string. Thus, it seemed like the normal way to execute a string, lol.[/color]
>
> But why did that seem like it should be the normal way
> to do variable assignment to global?
>
> BTW, locals() doesn't work like you want in part because
> that prevents a performance optimization where local
> variable lookups are done in O(1) time as an offset
> into a fixed size table. I suppose it would be possible
> to have locals() be able to manipulate that table behind
> the scenes, but then that would be complicated and complex.[/color]

Very -- and for no good purpose, because just about every beginner's
desire to "assign variables with names determined at runtime", once
analyzed in a bit more depth, turns out to be susceptible of some far
preferable approach (9 out of 10 involving some dict...).

BTW, any function incuding an 'exec' statement has the optimization you
mentioned turned off -- thus the whole function runs dog-slow...

Alex

help me

help me

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment