Double sided double underscored variable names

[Steven D'Aprano]

Sorry for breaking threading, but Joshua's post does not show up on my 
usenet provider.

On Wed, 12 Sep 2012 08:22:17 +1000, Chris Angelico wrote:

> On Wed, Sep 12, 2012 at 8:09 AM, Joshua Landau
> <joshua.landau.ws at gmail.com> wrote:
>>
>> If I were to use internal double-underscored names of the form
>> __BS_internalname__, would the compiled code be able to assume that
>> no-one had overwritten these variables and never will, 

Certainly not. It is virtually never possible to make that assumption in 
Python. Nearly everything can be shadowed at runtime.

(One exception is local variables of a function, which can only be seen 
from inside that function. But you don't need to wrap local variable 
names in underscores to treat them as local.)

Dunder ("Double leading and trailing UNDERscore") names are normal names 
subject to the same rules as anything else in Python (with one 
exception), which means you can modify them in all sorts of ways at 
runtime:

py> _int = int
py> class MyInt(_int):
...     def __add__(self, other):
...             return 42
...
py> int = MyInt
py> a = int("10000")
py> a + 1
42
py> type(a).__add__ = lambda self, other: 23
py> a + 1
23


The one exception how dunder names are treated specially is that Python 
uses a short-cut for name-lookup which means you cannot override them on 
a per-instance basis like normal other attribute names.



>> even through modification of, say, locals().

Modifying locals() is an implementation detail which may not be supported.



>> I ask because Python's docs seem to
>> specify that double sided double underscored names are strictly for
>> Python and its special names.

Dunder names are reserved for use by Python's built-ins and syntax, that 
is all.


> Interesting. If you're compiling your code to Python, you may be able
> to, if necessary, adorn a user's variable name(s). I'd be inclined to
> use a single underscore notation like _BS_internalname_ and then, in the
> event of a collision (which would be incredibly unlikely unless
> someone's fiddling), rename the offending variable to _BS_BS_something_
> - which of course you'd never yourself use. Would that serve?

This seems to be a mere extension of the name-mangling that occurs with 
leading-only double-underscore attributes like self.__spam. This can be a 
right PITA at times, and offers so little protection that it isn't 
worthwhile. __names only protect against *accidental* name collisions, 
and not all of those.


-- 
Steven