Le Tuesday 12 August 2008 23:15:23 Calvin Spealman, vous avez écrit :
The issue has been brought up several times before. There have been
proposals to make nested classes better supported, but they are always
shut down. The vote is always against it. Your metaclass example is
one thing, but its not really applicable here. I've never seen or
would encourage nested classes even in that case. The metaclass is
typically defined on its own, and then referenced by one or more
classes that use it. Defining it as a nested class saves you one line
of code, but IMHO makes the result just a bit more cluttered, while
reducing the elegance of reusing the metaclass.
>
Here are only a few examples of threads giving good reasons against
class nesting. I've never seen any good arguments for it. There are
dozens of good reasons we don't encourage it and won't actively
support it.
>
>
proposals to make nested classes better supported, but they are always
shut down. The vote is always against it. Your metaclass example is
one thing, but its not really applicable here. I've never seen or
would encourage nested classes even in that case. The metaclass is
typically defined on its own, and then referenced by one or more
classes that use it. Defining it as a nested class saves you one line
of code, but IMHO makes the result just a bit more cluttered, while
reducing the elegance of reusing the metaclass.
>
Here are only a few examples of threads giving good reasons against
class nesting. I've never seen any good arguments for it. There are
dozens of good reasons we don't encourage it and won't actively
support it.
>
>
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 :
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)
(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(typ e_) :
class dynamic(object) :
type_ = type_
return dynamic
--
_____________
Maric Michaud