Why less emphasis on private data?
Steven D'Aprano
steve at REMOVE.THIS.cybersource.com.au
Mon Jan 8 05:37:55 EST 2007
On Sun, 07 Jan 2007 23:49:21 -0800, Paul Rubin wrote:
> Steven D'Aprano <steve at REMOVEME.cybersource.com.au> writes:
>> Just how often do you inherit from two identically-named classes
>> both of which use identically-named private attributes?
>
> I have no idea how often if ever.
You've established that there's a name conflict when you do so, which
leads to bugs. So how often do you get bitten by that particular type of
bug?
> I inherit from library classes all
> the time, without trying to examine what superclasses they use. If my
> subclass happens to have the same name as a superclass of some library
> class (say Tkinter) this could happen. Whether it ever DOES happen, I
> don't know, I could only find out by examining the implementation
> details of every library class I ever use, and I could only prevent it
> by remembering those details.
class MySubClass(SomeSuperclass):
try:
__my_private_attribute
except AttributeError:
__my_private_attribute = some_value
else:
raise ValueError("Name conflict with private attribute!")
Problem solved.
*wink*
> That is an abstraction leak and is
> dangerous and unnecessary. The name mangling scheme is a crock. How
> often does anyone ever have a good reason for using it,
Exactly. I never use it.
The truth of the matter is, MyClass.__private is not private at all. It is
still a public attribute with a slightly unexpected name. In other words,
if you want to code defensively, you should simply assume that Python has
no private attributes, and code accordingly.
Problem solved.
--
Steven.
More information about the Python-list
mailing list