On Wed, Aug 13, 2008 at 11:32 AM, Cousson, Benoit <b-cousson@ti.comwrote:

>
The whole point of nested class is to avoid polluting the namespace with classes that are only used locally. So the argument about the elegance of reusing is not very valid in that case.

There is no point of nested classes because nested classes _are not_
supported by python. They are simply an artifact of not actively
denying the syntax non-globally. I would fully support a change to the
language to actively forbid a class definition that is not
module-level.

I agree that they are other ways using module to avoid namespace pollution, but in some case it is easier to use nested class instead and keep everything in the same file.

I don't consider it pollution. If you want it considered "private" to
the module, name it with an underscore.

In my case, I'm trying to use a similar approach as XIST's one, meaning using Python class to model hierarchical data. So clearly nested class is a very nice and easy understandable way to do that.

I don't find that this is clear in anyway. I can't imagine why you'd
think a nested class is even useful here, rather than an instance with
some understandable attributes. I've seen a lot of places nested
classes are used and not one of them that should be been doing it.

But, on that note, there is a point where a discussion is obviously
not going to resolve with either side changing their minds. This is
obviously such a case.

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

On Aug 13, 11:38*am, "Calvin Spealman" <ironfro...@gmail.comwrote:

On Wed, Aug 13, 2008 at 11:32 AM, Cousson, Benoit <b-cous...@ti.comwrote:

>

>
There is no point of nested classes because nested classes _are not_
supported by python. They are simply an artifact of not actively
denying the syntax non-globally. I would fully support a change to the
language to actively forbid a class definition that is not
module-level.

I think that's taking it a little too far. It's not unreasonable to
throw small, private use classes into the class definition, like so:

class Someting(object):
class PrivateException(Exception):
pass


And inside function a class definition can make a lot of sense.
Oftentimes I write a quick adaptor class because I want to pass
something to code that expects something else, for instance:

def some_function(lines):
class FileMimicker(object):
def __init__(self):
self.index = 0
def readline(self):
line = lines[self.index]
self.index += 1
return line
function_that_calls_readline(FileMimicker())


(Why would I want to clutter up my module's namespace for that silly
thing?)

So I see no good reason for the compiler to disallow nested class
statements; it's occasionally useful and not a common pitfall.


Carl Banks

On Wed, Aug 13, 2008 at 10:49 PM, Carl Banks <pavlovevidence@gmail.comwrote:

>
I think that's taking it a little too far. It's not unreasonable to
throw small, private use classes into the class definition, like so:
>
class Someting(object):
class PrivateException(Exception):
pass
>
And inside function a class definition can make a lot of sense.
Oftentimes I write a quick adaptor class because I want to pass
something to code that expects something else, for instance:
>
def some_function(lines):
class FileMimicker(object):
def __init__(self):
self.index = 0
def readline(self):
line = lines[self.index]
self.index += 1
return line
function_that_calls_readline(FileMimicker())
>
>
(Why would I want to clutter up my module's namespace for that silly
thing?)
>
So I see no good reason for the compiler to disallow nested class
statements; it's occasionally useful and not a common pitfall.
>
Carl Banks

I know every rule has its exceptions. I put "don't nest classes" in
with other similar rules I will claim, where I think its safest to say
"Never do this!", because only then will you know that, should you
actually do it at some point, you've got a reason good enough to break
a "rule".

As for the cluttering of the namespace, I don't buy it. Sure there are
cases to be made to reduce the number of names in any scope, but I
don't see a big advantage here. Its still accessible from the module,
just though the class. I also don't see any examples of nested classes
that wouldn't be useful elsewhere, your example included. For that
matter, your example should just being using StringIO.

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

On Wed, 13 Aug 2008 23:40:50 -0400, Calvin Spealman wrote:

I know every rule has its exceptions. I put "don't nest classes" in with
other similar rules I will claim, where I think its safest to say "Never
do this!", because only then will you know that, should you actually do
it at some point, you've got a reason good enough to break a "rule".

I would put it like this:

"Never nest classes, unless you need to, or to win a bet."

I've never yet needed to nest a class inside a class, but I've used a
"class factory function", a function that returned classes.


--
Steven

Calvin Spealman a écrit :

On Wed, Aug 13, 2008 at 11:32 AM, Cousson, Benoit <b-cousson@ti.comwrote:

(snip)

There is no point of nested classes because nested classes _are not_
supported by python.

Depending on the definition of "supported".

(snip)

>
I don't find that this is clear in anyway. I can't imagine why you'd
think a nested class is even useful here, rather than an instance with
some understandable attributes.

I onced played with the same idea, ie using nested classes as a
declarative approach to XML/HTML generation. It didn't quite work - at
least not well enough to be worth spending more time on the topic - but
at least I can imagine why the OP thinks "true" nested classes would
have help here.

Calvin Spealman a écrit :
(snip)

I know every rule has its exceptions. I put "don't nest classes" in
with other similar rules I will claim, where I think its safest to say
"Never do this!",

I know (from experience) and understand why goto's and globals are
(usually) evil, I know why public attributes can be harmful - in
languages that don't support computed attributes, that is -, well, I can
understand and explain most of the usual and some less known "golden
rules" (law of demeter etc), and even a couple very local or
yet-unwritten ones (monkeypatch anyone ?), but I definitively fail to
see what's your problem with nested classes.