[Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages

[Laura Creighton]

In a message of Sat, 25 Jul 2015 16:08:03 -0500, boB Stepp writes:
>After having a long discussion with my wife on her user requirements,
>I am convinced that an OO approach is required.  Which is just as well
>as that has been one of my next areas of learning to do.  I am
>currently reading "Python 3 Object Oriented Programming" by Dusty
>Phillips, which so far seems to be a reasonably good text.  This has
>led me to the subject line topics.
>
>>From my understandings to date:
>
>1) A single underscore is used conventionally for a "throw-away"
>variable, such as a loop index for which the index value is not
>actually used in a subsequent calculation.

Some people do this.  I find it irritatingly twee, and hard to read
as well.  I like 'junk' for such things.

>2) _name is used inside class methods to indicate that the
>programmer's intention is that this name should only be accessed
>internally by that particular class.  Other supposedly "adult" Python
>programmers will attempt to respect this original intent if they use
>my code.

The world is packed very full of Python programmers who have never
heard of this rule, and thus this is sort of a 'pious hope' more
than anything else.  The world is also full of python modules that
have no single underscore variable names at all.

>3) __name invokes Python's name mangling mechanism.  The intent of
>this usage is to not allow subclasses of the class containing __name
>to access this name, and to add additional emphasis to future users of
>my code that this name is meant to be strictly hands-off.

worry about this when you want to share your code with the world
and don't want new users to be able to rely on things to always be
the way you have it right now.

i.e. adding double underscores is often the last thing you do
before release.

>4) name_ is used when one is "forced" to use one of Python's reserved
>words as a name.

You are never forced to.  Sometimes you might want to.  Sometimes
name_ is a good choice in this case.  But in my life 'stop
wanting this, you arrogant wretch' has mostly been the correct
thing. :)  (At least I think never.  Maybe I am being an arrogrant
wretch here, too.)

>5) __name__ is meant to be used only by the creators of Python for
>their special built-in methods, such as __init__, __new__, etc.
>
>Are my understandings above correct or flawed?

Pretty much dead on.

>
>For (3), it seems to me that one would normally be able to use the
>simpler _name construction from (2).  What would be a best-practice
>example of when name mangling *should* be used?

If you do not mangle the names, you are making a promise, sometimes
a half-hearted promise, that through the life of the code
other people can come by and use these methods, with exactly
this signature, and it will just work.  This is called 'being
Part of the public API'.  If you publish such things and then,
next release, remove those methods or change the number or
order of the arguments .... their code will break.

If its just you and your tapeworm, you don't care and you make and
remove methods and signatures all the time.  If people do not like it,
tough, and so it goes.  It's what they get for running your experimental
software.

If you publish your code as a module on PyPI people will find ways to
use the public API, so if you want to reserve the right to delete
this method later, or change it's signature then by all means mangle
the thing.

In the Python world people are generally less worried about what
will happen if some wretch gets a hold of a method that I didn't
really want as part of the public API than what will happen
if they badly need to get a hold of a method and I didn't make
it possible.  This makes for a lot of the single underscore
variables.  'I don't want to make it impossible for you to
access things this way, but I wish you wouldn't' more or less.

>
>Likewise, it seems that normally (4) should never be needed, though I
>have a feeling that I have seen something in tkinter recently that
>suggests some exceptions, but I cannot (yet) bring it to mind.

Not sure what you are thinking about.

>And for (5), surely I should never violate this one?  It seems that in
>some future edition of Python they might add any particular __name__
>that I might try to use presently in their future version of Python
>(however miniscule that possibility might actually be).

Right.  Don't go there.

>
>Thanks!
>boB
>
>-- 
>boB

MY .02 euros.

Others will have other ideas.

but that is the way I see it.

Laura