Protecting instance variables

[Bruno Desthuilliers]

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" <deets at nospam.web.de> 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.