On 01/04/2014 06:32 AM, Keith Winston wrote:
On Fri, Jan 3, 2014 at 11:59 PM, Steven D'Aprano <st...@pearwood.info>wrote:
thelist = vars()[name]
I see: vars() certainly looks less dangerous than eval(), but I'm guessing
that's still smelly code? I hadn't known about vars() or I probably would
have used it.
It is not as much smelly as somewhat "meta". It talks about Python's own
conception, here about scopes (or namespaces). [I will let so-called
"non-locals" aside, for simplicity.] Imagine that Python provided 2 dicts,
always there:
* top_vars, for vars defined at top module level (included imports)
* local_vars for function local vars (included inputs)
Then, you could write:
a = 1
def f ():
top_vars.a = 2 # redef / change symbol a
local_vars.b = 1 # def / create symbol b
print(top_vars.a, local_vars.b)
which is the same as actual Python code:
a = 1
def f ():
global a
a = 2
b = 1
print(a, b)
but shows more or less how things work behind the stage.
local() and globals() return a dict equivalent to my imaginary local_vars and
global_vars, resp. [But in the actual implementation, things are somewhat more
low-level for efficiency; esp. IIRC locals are not truely named if you don't ask
for them, as in most dynamic langs; but I may be wrong]. If Python scope were
simply, truely, directly Python data (dicts), without the need to call a
function that fabricates the dict on need, then the language would be
"homoiconic" (on this aspect of its functioning), which just means that it works
using its own data (types). Thus, the "meta" view.
vars() is somewhat special, works for any namespace-like component. See:
http://docs.python.org/3/library/functions.html
for a few details.
Denis
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
