Pseudo-Private Class Attributes

[Bruno Desthuilliers]

Ricardo Aráoz a écrit :
> That is self.__attributes
> 
> Been reading about the reasons to introduce them and am a little
> concerned. As far as I understand it if you have a class that inherits
> from two other classes which have both the same name for an attribute
> then you will have a name clash because all instance attributes "wind up
> in the single instance object at the bottom of the class tree".
> 
> Now I guess this means that in any real OOP project you'd better use
> __attr for all your attributes, because classes are usually meant to be
> subclassed and you can never know when you'll be subclassing from two
> classes with attributes with the same name, and I guess you can't take
> the risk of this happening because when it happens it will be hell to
> find out what's going on.
> 
> Is this right?

Wild guess : you're coming from Java or C++ ?-)

I don't know for sure what you mean by "real OOP project", but any 
non-trivial Python project surely qualifies IMHO, and it seems that so 
far no one had too much problem with this, so you're perhaps needlessly 
worrying.

Note that given Python's type system, inheritence is mostly about 
implementation - you don't need it for polymorphic dispatch. This 
results in class hierarchies being way much flatter in Python than in 
languages with declarative static typing - IOW, Python's classes are not 
necessarily "meant to be subclassed".

Also, while Python does support multiple inheritance, it's rarely used 
in practice (except perhaps in Zope 2, which is that pythonic). Python 
has great support for delegation, so composition/delegation is often 
used where MI would have been used in C++.

FWIW, __private names are of very rare use in Python. As far as I'm 
concerned, I must have use this feature a couple of times at most, in 
base classes or metaclasses of a small framework, because these couple 
attributes where really vital to the sytem and should by no mean be 
overloaded.

My 2 cents.