How do I do this? (eval() on the left hand side)

[Nick Coghlan]

Modifying globals() not even necessary for this. When I want to
dynamically update the global namespace, I do it this way:

mod = __import__(__name__)
setattr(mod,symbol,value)

Works perfectly unless you're worried about someone modifying the built
in __import__.

Well, aside from the detail that modifying a module's contents via a reference
to that module is far more evil than playing with globals()

Even if that module is the one you're running in. . .

Cheers,
Nick.

 

[Mel Wilson]

The thing is, that once you drop local-namespace
optimization, the entire function gets slowed down, possibly
by 40%:

It's not that bad as most of the extra time is spend on compiling the
string. [ ... ]
def fib7(n, c=compile("a, b, i = 0, 1, n", "<nofile>", "exec")):
exec c

[ ... ]

!


Regards. Mel.

 

[Carl Banks]

Well, aside from the detail that modifying a module's contents via a reference
to that module is far more evil than playing with globals()

Even if that module is the one you're running in. . .

It seems to me that that which makes modifying a module's contents via
a reference evil makes modifying them via globals() equally evil. The
only thing is, modifying them through a module reference is explicit
and straightforward, whereas modifying the contents via globals() is an
implicit, backhanded trick that relies on certain behind-the-scenes
behavior.

I'd say using globals() is far eviler. So I must disagree with your
good-natured objection. Unless there's some practical weakness of
using references that I am unaware of.

 

[Peter Hansen]

I'd say using globals() is far eviler.

I don't understand either of you. ;-)

From my point of view, they're basically identical, and
although I find Carl's approach slightly less explicit
and harder to read (mainly the uncommon __import__ call,
but it's not a big deal), I can't see why either of them
would be considered evil.

Changing a module's contents via globals() is a very common
and surely benign thing to do.

-Peter

 

[Carl Banks]

From my point of view, they're basically identical, and

although I find Carl's approach slightly less explicit
and harder to read (mainly the uncommon __import__ call,
but it's not a big deal), I can't see why either of them
would be considered evil.

Of course, when I said evil, I didn't mean evil, I meant Evil(tm). I
suspect Nick meant so as well.

Personally, I just think __import__(__name__) is a bit more honest than
globals() for a simple reason.

What are you doing? You're changing module attributes. Well, here's
the module object. You're using setattr on the module object to set
module attributes.

What are you doing? You're changing module attributes. Well, here's
the module's dict. You're using dictionary access on the modules dict
to set modules attributes.

It's a bit more honest to set module attributes using setattr than dict
access, I would say. That's why I prefer it. I admit, it's pretty
weak. (But then again, so is __import__ being uncommon. It's not a
big deal which you choose, as you say. Although I don't use globals()
in this way, I do modify object dicts to get the effect of changing
object attributes from time to time (mostly to take advantage of dict
methods, which I could see being a reason to use globals() as well).

 

[Peter Hansen]

It's a bit more honest to set module attributes using setattr than dict
access, I would say.

Granted.

But I think it's also more honest to change a module's dict by
using globals() than by using a setattr call. <0.500 wink>

-Peter