[ python-Bugs-1539847 ] Identifiers begining with __ renamed

SourceForge.net noreply at sourceforge.net
Wed Aug 16 06:29:44 CEST 2006


Bugs item #1539847, was opened at 2006-08-14 15:47
Message generated for change (Comment added) made by w_barnes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: W Barnes (w_barnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Identifiers begining with __ renamed

Initial Comment:
Identifiers used in a class function that start with 
__ are renamed to _classname__identifer even if the 
identifier is owned by some other object.

Code snippet:

size = len(Data.__entry_dates)

Here I'm trying to access the identifier 
__entry_dates in the module Data from the function 
DataTestCase.testEntryDates() but I get the following:

Traceback (most recent call last):
  File "DataTest.py", line 247, in testEntryDates
    size = len(Data.__entry_dates)
AttributeError: 'module' object has no 
attribute '_DataTestCase__entry_dates'

I'm using Python 2.4.3 on Windows XP sp2

Thanks,
Walter

----------------------------------------------------------------------

>Comment By: W Barnes (w_barnes)
Date: 2006-08-16 12:29

Message:
Logged In: YES 
user_id=1541460

I just noticed some more weirdness in regards to name 
mangling...

Apparently there is no way for a class to access global 
attributes that are declared private. That is if a 
module 'foo' has a global attribute '__widget' a 
class 'bar' also defined in foo will get the following 
error if it attempts to access __widget:

NameError: global name '_bar__widget' is not defined

Using either _foo__widget directly or __dict__ doesn't 
work.

For now, I can get around this by using a non-private 
global helper function as a middle man.

I'm a Python newbie but, for what it's worth, here are 
some suggestions:

First, if an attribute is accessed as a child of some 
object other than 'self' or the name of the enclosing 
class no name mangling should be done. It seems that name 
mangling isn't necessary here as an attribute error will 
all ways be raised whether or not the object has that 
attribute.

Second, when searching for a global attribute that begins 
with __ it should be renamed to reflect the name of the 
module not the enclosing class. In the example above, if 
_bar__widget cannot be found in bar then it should look 
for _foo__widget in the global namespace.

Finally, as I mentioned before, for clarity if no match is 
found the error message should include the unmangled name.

----------------------------------------------------------------------

Comment By: W Barnes (w_barnes)
Date: 2006-08-16 10:10

Message:
Logged In: YES 
user_id=1541460

Thanks!

I was unaware that name mangling applied to global 
attributes as well as class attributes.

The error message is a bit misleading though. If I define 
__widget in foo then access it from bar as foo.__widget 
why does it rename it as _bar__widget if it was not 
defined there? If it needs to do this internally why not 
use the unmangled name for the error message?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-14 16:07

Message:
Logged In: YES 
user_id=849994

This is exactly how __ name mangling is supposed to work.
These are meant to be private, and thus shouldn't be
accessed from another class.

If the attribute was in another class, you could do the
mangling (with the correct class name!) yourself, as it's on
a module in this case, use __dict__:
size = len(Data.__dict__['__entry_dates'])

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470


More information about the Python-bugs-list mailing list