Nikolaus Rath a écrit :
Hi,
Sorry for replying so late. Your MUA apparently messes up the
References:, so I saw you reply only now and by coincidence.
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
Nikolaus Rath schrieb:
Hello,
I am really surprised that I am asking this question on the mailing
list, but I really couldn't find it on python.org/doc.
Why is there no proper way to protect an instance variable from access
in derived classes?
I can perfectly understand the philosophy behind not protecting them
from access in external code ("protection by convention"), but isn't
it a major design flaw that when designing a derived class I first
have to study the base classes source code? Otherwise I may always
accidentally overwrite an instance variable used by the base class...
Here we go again...
http://groups.google.com/group/comp.lang.python/browse_thread/thread/188467d724b48b32/
To directly answer your question: that's what the __ (double
underscore) name mangling is for.
I understand that it is desirable not to completely hide instance
variables. But it seems silly to me that I should generally prefix
almost all my instance variables with two underscores.
Why on earth would you protect "almost all" your attributes ???
I am not so much concerned about data hiding, but about not
accidentally overwriting a variable of the class I'm inheriting from.
>
And, unless I misunderstood something, this is only possible if I'm
prefixing them with __.
How is this problem solved in practice?
Which "problem" ?-)
What your afraid of almost never happens. FWIW, it *never* happened to
me in now 8+ years. And I almost never use __name_mangling_protection
(I'd say about half a dozen times, and mostly because I was getting a
bit paranoid on these occasions).
I probably don't have a
representative sample, but in the libraries that I have been using so
far, there were a lot of undocumented (in the sense of: not being part
of the public API) instance variables not prefixed with __.
Oh, while we're at it: the convention for "protected" attributes (that
is: not part of the API, but ok to override) is to use a single leading
undescore.
I have
therefore started to first grep the source of all base classes
whenever I introduce a new variable in my derived class. Is that
really the way it's supposed to be? What if one of the base classes
introduces a new variable at a later point?
Well... Since Python is dynamicall typed, and since it has good support
for composition/delegation, type hierarchies tends to be *way* much
flatter than in Java or C++. So there's way less name collision hazards.
As I said, what you fear just never happened to me so far, even in
frameworks like Zope which is probably where you'll find the worst case
of deep type hierarchies and multiple inheritance abuse in Python.
IOW : unless your code suddenly breaks in strange ways after you've
added a new attribute (or renamed one), just don't worry.
--
http://mail.python.org/mailman/listinfo/python-list
