Why nested scope rules do not apply to inner Class?

[Calvin Spealman]

On Wed, Aug 13, 2008 at 7:41 PM, Maric Michaud <maric at aristote.info> wrote:
> I was not aware of any "nested classes are unsupported" before and didn't
> consider nested classes as bad practice till now, even with the pickle
> limitation (not every class are intended to be pickled), more you didn't give
> any evidence or any pertinent quote of this and at least one of Guido in the
> above threads seems contradict you :
> http://mail.python.org/pipermail/python-dev/2002-November/029906.html

Of course, I don't have to agree with Guido, but I don't really think
his comment there counts as some encouragement of the practice. It
also isn't an example that actually demonstrates the things people
misuse about nesting classes, although its definitely an example that
I think could be done much better without them, at all.

The use of nested classes to define some hierarchical structure is
subject, at best. And, the examples I see aren't even hierarchical.
The nesting doesn't seem to gain them anything. As a matter of fact,
wouldn't that example be a lot more clear with one class and some
"Attribute" properties describing the structure?

What rubs me the wrong way about nested classes is that they aren't
even "real" classes. That is, they aren't being used to instantiate
instances, but just as dummy scopes to hold some attributes. They are
abusing classes as property bags.

> BTW my concern was not really about nested classes but the asymetry between
> function scope and classes scope, there are at least two examples that come
> to my mind and for which I don't see good argument to keep the situation as
> it is. First is the very odd behavior of genexp, second is the dynamic type
> factory, I know it's not a big deal to in each case and can live with this,
> but these pieces of code fail unexpectedly while even a experimented python
> programmer would have thought they work at first glance, and the explanation
> of why they fail to a newcomer is not easy (specially for the first)
>
> (1) this fail  only on the last line while it would have work well with
> listcomp and works well in a function definition
> class A(object) :
>    l = range(5)
>    m = list(a+b for a in l for b in range(5))
>    n = list(a+b for a in range(5) for b in l)

I can admit that this behavior can be surprising, but it isn't
something I really see cropping up as a problem. How often do you see
that you need to have any kind of procedural behavior in a class body?
In other words, in all but rare cases, the order of the class body
lines shouldn't change the resulting class, but this example breaks
that expectation.

> (2) This won't work as it would with nested functions, you need to build the
> new calss directly with type('dynamic', (object,), {"type_": type_})
>
> def create_type(type_) :
>    class dynamic(object) :
>        type_ = type_
>    return dynamic

This is simply completely invalid. That code at the beginning of any
body will _always_ raise either an UnboundLocalError or a NameError,
because you are assigning to the same name you are dereferencing. That
line will always be either an error or a no-op, anywhere it appears.
It has nothing to do with nesting of any sort.

>
> --
> _____________
>
> Maric Michaud
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy