<div class="gmail_quote">On 12 September 2012 01:51, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve+comp.lang.python@pearwood.info" target="_blank">steve+comp.lang.python@pearwood.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry for breaking threading, but Joshua's post does not show up on my<br>
usenet provider.<br></blockquote><div> </div><div>That may explain why I keep getting ignored -.-</div><div>I thought it was something I said :P</div><div><br></div><div>I'm just using EMail through GMail, posting to <a href="mailto:python-list@python.org">python-list@python.org</a>. If that is the wrong way, I would love to know what I should be doing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 12 Sep 2012 08:22:17 +1000, Chris Angelico wrote:<br>
<div class="im"><br>
> On Wed, Sep 12, 2012 at 8:09 AM, Joshua Landau<br>
> <<a href="mailto:joshua.landau.ws@gmail.com">joshua.landau.ws@gmail.com</a>> wrote:<br>
>><br>
>> If I were to use internal double-underscored names of the form<br>
>> __BS_internalname__, would the compiled code be able to assume that<br>
>> no-one had overwritten these variables and never will,<br>
<br>
</div>Certainly not. It is virtually never possible to make that assumption in<br>
Python. Nearly everything can be shadowed at runtime.<br>
<br>
(One exception is local variables of a function, which can only be seen<br>
from inside that function. But you don't need to wrap local variable<br>
names in underscores to treat them as local.)<br>
<br>
Dunder ("Double leading and trailing UNDERscore") names are normal names<br>
subject to the same rules as anything else in Python (with one<br>
exception), which means you can modify them in all sorts of ways at<br>
runtime:<br>
<br>
py> _int = int<br>
py> class MyInt(_int):<br>
... def __add__(self, other):<br>
... return 42<br>
...<br>
py> int = MyInt<br>
py> a = int("10000")<br>
py> a + 1<br>
42<br>
py> type(a).__add__ = lambda self, other: 23<br>
py> a + 1<br>
23<br></blockquote><div><br></div><div>Fair play.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The one exception how dunder names are treated specially is that Python<br>
uses a short-cut for name-lookup which means you cannot override them on<br>
a per-instance basis like normal other attribute names.<div class="im">
<br>
>> even through modification of, say, locals().<br>
<br>
</div>Modifying locals() is an implementation detail which may not be supported.</blockquote><div><br></div><div>Nice to know.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
>> I ask because Python's docs seem to<br>
>> specify that double sided double underscored names are strictly for<br>
>> Python and its special names.<br>
<br>
</div>Dunder names are reserved for use by Python's built-ins and syntax, that<br>
is all.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Interesting. If you're compiling your code to Python, you may be able<br>
> to, if necessary, adorn a user's variable name(s). I'd be inclined to<br>
> use a single underscore notation like _BS_internalname_ and then, in the<br>
> event of a collision (which would be incredibly unlikely unless<br>
> someone's fiddling), rename the offending variable to _BS_BS_something_<br>
> - which of course you'd never yourself use. Would that serve?<br>
<br>
</div>This seems to be a mere extension of the name-mangling that occurs with<br>
leading-only double-underscore attributes like self.__spam. This can be a<br>
right PITA at times, and offers so little protection that it isn't<br>
worthwhile. __names only protect against *accidental* name collisions,<br>
and not all of those.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>* When it's done, of course</div></div>