metaclass and customization with parameters
aleaxit at yahoo.com
Wed Oct 6 19:02:20 CEST 2004
Gustavo Niemeyer <niemeyer at conectiva.com> wrote:
> Hello Alex!
> > > Of course, in your example, not using the 'i=i' trick would be a
> > > problem, since the 'i' variable is lost, and inside the method a
> > > global is looked for, creating an error.
> > True, the opcode for i is indeed a LOAD_GLOBAL. Why _that_ should be
> > the case is anything but an 'of course' to _me_, though, as we just
> Sorry, my intention was to say that removing "i=i" would be
> clearly a problem, not that the whole issue was clear.
Sorry, I should have inserted smilies -- I did get your intended meaning
and was just playing around with the words!
> > any potential confusion here) to specifically ensure that -- I guess
> > it's for backwards compatibility with old Python versions which didn't
> > have nested scopes, otherwise any barename in a method would refer first
> In this case, the external closure must be the global scope, otherwise,
> code like this:
> class C:
> var = 1
> def method(self):
> print var
> Would show self.__class__.var, when it shouldn't.
IMHO the only reason it shouldn't is backwards compatibility with old
Python versions, as I mentioned above. It's a good reason, mind you,
but maybe in Python 3000 we can rethink this issue, too.
> > to the classbody (acting as its 'outer function') which could shadow
> > globals. A bit confusing for an "of course", nevertheless;-).
> Again, I'm sorry. My "of course" should be more closely related to the
> fact that removing "i=i" would be a problem, as was my original
> intention. Even if the internal 'i' was bound to a closure, as you
> seem to belive would be the expected behavior, the OP's code would end
> up doing the wrong thing.
Exactly, and _that_ would be the normal way to fail -- omitting to
"snapshot" some variables, of which we want the _current_ value, and
which may still be changing... (incidentally a strong argument against
certain... hmmmm... "beings", who claim it's "undisputably wrong" that
default values get evaluated ONCE, at def-time...).
More information about the Python-list