[Python-3000] Change to class construction?

Guido van Rossum guido at python.org
Sat Jul 7 01:41:16 CEST 2007


On 7/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

Understood, but a generator expression (and hence in 3.0 also a list
comprehension) is treated the same as a method body.

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


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list