help me

[Chris Patton]

Hey everybody. I am writing a program that requires the user to make
the name for variables inside the program. For example:

However, I don't want to have to use the "exec" statement. Thanks for
any help!

P.S. For those who have ansewered my post for a similar request, I
thought this would explain myself better.

---

 

[Marius Bernklev]

Hey everybody. I am writing a program that requires the user to make
the name for variables inside the program. For example:


However, I don't want to have to use the "exec" statement. Thanks for
any help!

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

 

[dataangel]

(e-mail address removed) (Chris Patton) writes:




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

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]

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

 

[Peter L Hansen]

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.

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

 

[Andrew Dalke]

dataangel:

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.

That's not the normal way. Where did you get that idea?
enter name: import os; os.system("pwd && echo rm -rf /delete/any/file"); c
/Users/dalke/src
rm -rf /delete/any/file
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.
Traceback (most recent call last):

>>> globals()[raw_input("enter name: ")] = 34 enter name: spam
>>> spam 34
>>>

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'?

>>> globals()[raw_input("enter name: ")] = 34 enter name: raw_input
>>> globals()[raw_input("enter name: ")] = 34

Traceback (most recent call last):

Andrew
(e-mail address removed)

 

[Richard Blackwood]

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

He's got to learn somehow! LOL

 

[dataangel]

He's got to learn somehow! LOL

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]

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.

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
(e-mail address removed)

 

[Richard Blackwood]

globals()[raw_input("enter name: ")] = 34 enter name: raw_input
globals()[raw_input("enter name: ")] = 34

Traceback (most recent call last):

Andrew
(e-mail address removed)

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]

globals()[raw_input("enter name: ")] = 34 enter name: raw_input
globals()[raw_input("enter name: ")] = 34

Traceback (most recent call last):

Andrew
(e-mail address removed)

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.

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]

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?

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]

> 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.

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

Andrew
(e-mail address removed)

 

[Richard Blackwood]

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

Andrew
(e-mail address removed)

Indeed.

 

[Alex Martelli]

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.

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