"private" variables a.k.a. name mangling (WAS: What is print? A function?)

[Toby Dickenson]

On Tuesday 25 January 2005 12:40, Richie Hindle wrote:
> 
> [Steven]
> > Can someone give me an example of where __-mangling really solved a 
problem 
> > for them, where a simple leading underscore wouldn't have solved the 
> > same problem?
> 
> 
http://cvs.sourceforge.net/viewcvs.py/spambayes/spambayes/spambayes/Dibbler.py?r1=1.13&r2=1.13.4.1
> 
> That's a bugfix to SpamBayes, where I'd inadvertently named an instance
> variable '_map' without realising that the base class
> (asynchat.async_chat) also had an instance variable of that name.  Using
> double underscores fixed it, and had I used them from the beginning the
> bug would never have cropped up (even if asynchat.async_chat had an
> instance variable named '__map', which is the whole point (which you know,
> Steven, but others might not)).

I have a counterexample. Consider refactoring a class from....

class B(A):
    etc

....into....

class C(A):
    etc
class B(C):
    etc

Usage of some double-undescore attributes moved from B to the new intermediate 
base class C. Unit tests on B still passed, so that change is safe. right?

The problem occured because the double-underscore mangling uses the class 
name, but ignores module names. A related project already had a class named C 
derived from B  (same name - different module). My refactoring caused 
aliasing of some originally distinct double-underscore attributes.

-- 
Toby Dickenson

____________________

Important Notice:

This email and any attachments are confidential and may contain trade secrets or be legally privileged. If you have received this email in error you must not use, rely upon, disclose, copy or distribute the contents. Please reply to the sender so that proper delivery can be arranged and delete the email from your computer.
Gemini Data Loggers monitor incoming and outgoing email to ensure satisfactory customer service, maintain company security and prevent abuse of their email system. However, any views expressed in this email are not necessarily those of Gemini and Gemini cannot be held responsible for the content.
Gemini makes best efforts to ensure emails are virus free; however you are advised to carry out your own checks. Gemini does not accept responsibility for any damage resulting from email viruses.
____________________