Chris Mellon wrote: > Private data in the C++ and Java OO worlds is so taught so much and > emphasized so often that people have started thinking of it as being > desirable for its own sake. But the primary motivation for it grew out > of the need to maintain compatible interfaces.
This is generally true, yes. [...] > Python doesn't have these problems, so the only use for private > information is to warn your clients away from access to certain names. > There's no need for compiler enforcement of that, as a convention is > just as effective. You'll have to be more clear, here. If you're writing a subclass of some other class then any usage of private attributes in the superclass potentially provides the benefit of a free choice in attribute names in the subclass. If you wanted to warn people away from certain names, it would be the public attributes that would require the warning, noting that "your clients" in this context includes people extending classes as well as those merely instantiating and using them. > The remaining arguments are generally outgrowths of "but my code is > SECRET", which just isn't true in general, even less true of Python, > and not really a healthy attitude anyway. I don't care about secret attributes, and the namespace privacy aspect doesn't bother me enough to use private attributes anyway, especially since I'm the author of most of the superclasses I'm extending. But either providing namespace privacy or convenient tools to mitigate namespace sharing seems fairly important to me, at least. Paul -- http://mail.python.org/mailman/listinfo/python-list
