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

[Steven Bethard]

> class Debug_Stderr:
> __m_text = ''
> __m_log_text = None
> __m_dbg = None
> __m_refresh_count = 0

<rant>

I don't see the benefit in 99.9% of cases for making class variables
like this "private". If you don't want people to use them, simply use
the standard convention[1] for non-public variables:

class Debug_Stderr:
_text = ''
_log_text = None
_dbg = None
_refresh_count = 0

A lot of the time, it actually makes sense to make (at least some of)
the attributes public, e.g.:

class Debug_Stderr:
text = ''
log_text = None
dbg = None
refresh_count = 0

I don't know what all the variables in this specific example are
intended to be, but it certainly seems like something like
'refresh_count' might be useful to clients of the class.

Name mangling is there to keep you from accidentally hiding such an
attribute in a subclass, but how often is this really a danger? 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?

</rant>

Steve

[1] http://www.python.org/peps/pep-0008.html

 

[michele.simionato]

Name mangling is there to keep you from accidentally hiding such an

attribute in a subclass, but how often is this really a danger? 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?

Look at the "autosuper" implementation on Guido's descrintro paper;
there the
fact that you user __super instead of _super is essential.

However I have written tens of thousands of lines of Python code and
never
needed __protected variables except in a few experimental scripts for
learning purpose. So I agree that the need does not occur often, but it
is still an useful thing to have.
Michele Simionato

 

[Richie Hindle]

[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)).

 

[Toby Dickenson]

[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.
____________________

 

[Richie Hindle]

[Toby]

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).

Yikes! A pretty bizarre case, but nasty when it hits. I guess the
double-underscore system can give you a false sense of security.

 

[Steven Bethard]

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.

Very interesting. I hadn't ever really thought about it, but I guess
this shows that even __-mangling won't solve all of the
attribute-renaming problems...

A somewhat related problem is briefly discussed in Guido's autosuper
example:
http://www.python.org/2.2.3/descrintro.html#metaclass_examples
where a base class derived from a class using autosuper but with the
same name as the superclass might get the wrong self.__super.

Steve