[Python-3000] Change to class construction?

[Phillip J. Eby]

At 12:32 AM 7/7/2007 +0200, Guido van Rossum wrote:
>On 7/6/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 05:00 PM 7/6/2007 +0200, Georg Brandl wrote:
> > >Collin Winter schrieb:
> > > > While experimenting with porting setuptools to py3k (as of r56155), I
> > > > ran into this situation:
> > > >
> > > > class C:
> > > >   a = (4, 5)
> > > >   b = [c for c in range(2) if a]
> > > >
> > > > results in a "NameError: global name 'a' is not defined" error, while
> > > >
> > > > class C:
> > > >   a = (4, 5)
> > > >   b = [c for c in a]
> > > >
> > > > works fine.
> >
> > This looks like a bug to me.  A list comprehension's local scope
> > should be the locals of the enclosing code, even if its loop indexes
> > aren't exposed to that scope.
>
>It's because the class scope is not made available to the methods.

The examples are in the class body, not in methods.  The code is 
statically initializing the class contents, so using C.a isn't possible.

I suppose it can be worked around by moving the static initialization 
code outside the class body; it's just not obvious why it happens.

Collin, where did you find this code in setuptools, btw?  I've been 
looking around at other packages of mine where static class 
initialization uses data structures like this, and I haven't found 
any place where anything but the "in" clause of a comprehension 
depends on class-scope variables.  So, if setuptools is the only one 
of my libraries that does this, I'd have to agree with Guido that it 
is indeed quite rare.  :)

If I had to hazard a guess, I'd guess that it's in one of the 
setuptools command classes that subclasses a distutils command, and 
proceeds to muck around with the original options in some fashion.  I 
just don't want to check all of them if you know which one it is.  :)