metaclass and customization with parameters

[Alex Martelli]

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


Alex