Double sided double underscored variable names

[Joshua Landau]

On 12 September 2012 01:51, Steven D'Aprano <
steve+comp.lang.python at pearwood.info> wrote:

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

That may explain why I keep getting ignored -.-
I thought it was something I said :P

I'm just using EMail through GMail, posting to python-list at python.org. If
that is the wrong way, I would love to know what I should be doing.


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

Fair play.


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


Nice to know.


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


The idea is that if they were reserved then nobody should ever use them.
They may be able to, yes, but if you are not meant to make any up, and
__BS_internalname__ isn't a Python-reserved name, then maybe I could claim
that it's safe territory.


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


I disagree. Not with your opinion on self.__spam, but on its equivalence to
the the mentioned idea. I have never used (due to absence of need) double
leading underscored names, but name mangling is a rigidly different concept
to simply naming a variable differently to another. As I can introspect my
own compiled code* (gasp!) I can check for any direct name clashes. Python
does not do the same with mangling, I believe.

It's not like I don't have options. I could always say
that inexplicit names have to be careful not to start with "_BS_" and then
deal nicely with the explicit ones as said above. But then, people aren't
going to be prepending "_BS_" explicitly unless they want to 'break' the
code.

If /you/ wanted to use a programming language that compiled to Python,
would you mind _BS_internalname_ variables littered around the place, and
would you prefer if they avoided as many conflicts as they can? I could
always make explicit conflicts a warning rather than avoid them. I'm not
sure what the practical choice is.

* When it's done, of course
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20120912/37138f52/attachment.html>