Bug or feature?

[Michael Hudson]

I don't want to keep banging on at this, I not entirely sure of all
the history behind it all; I might be wrong on some counts. But as
people are not understanding what I'm trying to say (most likely my
fault) I'll have another go...

dtj at rinconn.com (Derek Jones) writes:
> >> > > If this behavior is indeed what is intended, I'm really curious to
> >> > > know why.  Why is this confusing (to me at least) behavior considered
> >> > > desirable?
> >
> >The poster had already figured out for himself what was going on. He
> >asked "why is it this way?" - and I don't think it's to support class
> >data.
> 
> Really?  Because class variables are a feature found in other OO
> languages.  

Python is not those langauges.

> It doesn't seem like an accident to me.  Has GvR said anything
> one way or the other?

No, not that I've seen. I'm guessing.
 
> >> 2. Sometimes it is useful/necessary to save state or share information
> >> among all instances of a certain class.  One way to do that is to 
> >> declare a mutable data structure, such as your data1, at the class 
> >> level.  Then all instances can modify this shared data, and other 
> >> instances will immediately see the updates.  
> >
> >I have never used this technique. I don't think I've ever seen code
> >that does. Module-level globals are (IMHO) generally clearer. For a
> >start, if you want mutable data, you more-or-less have to wrap it up
> >in a list, and that's confusing.
> 
> Do you mean you've never seen Python code that does? 

No, I don't think so.

> I program an awful
> lot of C++, and there are reasons for using it there.  They're called
> "static class variables" sometimes, and are variables that are meant to be
> associated directly with that class.

That's C++ for heaven's sake! I know C++ far too well, you don't need
to explain to me what static variables are in C++. This is Python, I
know what they are here too, but they aren't (IMHO) as useful.

> Now, if you decide not to define more than one class per module, then yes,
> a module-level global is almost the same thing.  Python's approach to
> namespaces means that the programmer has to refer to the variable in code
> as <module>.<variable> -- unless they've used the "from" statement. 

It may be churlish to say it - but please don't patronize me.

> I think it comes down to expressing programmer intent.  

Well, quite.

> If you have 2+ 
> classes defined in a module and they need to share some global, that needs
> to be a module-level global.  If it only makes sense within that class, it
> seems desirable to associate that variable with that class name.

Maybe the Python code I write is unusual in that I vary rarely use
static variables of any kind. I don't know, it's just that something
about class variables makes me go "ick". I don't think they're good
style. Pythons module system makes module level globals much like
class (or more accurately namespace, I suppose) variables. 
 
> A final note:  static class variables (and methods, especially) make more
> sense in a language like C++, where users of a class are normally
> prevented from making use of the private data members of that class.  In
> Python, the only such protection is by convention, so class statics are
> not as *necessary*, but I still say that they can make the code easier to
> understand & maintain.

And I say they don't. 

We'll just have to disagree on this one, I suspect.

Have fun!

Michael