Why all the __double_underscored_vars__?

[kj]

Python is chock-full of identifiers beginning and ending with double
underscores, such as __builtin__, __contains__, and __coerce__.

Using underscores to signal that an identifier is somehow "private"
to an implementation is pretty common in languages other than
Python. But in these cases the understanding is that the use of
these variables in external code amounts to "going behind the API",
and is therefore unwise.

But as far as I can tell, Python's double-underscore variables are
very much part of Python's API. E.g., programmers are specifically
instructed to override "double-underscore methods" to achieve
certain functionalities.

In this case, I wonder: what justifiies the double-underscore
convention? For example, what would be the problem with changing
the name of the complex.__gt__ method to complex.gt?

TIA!

kynn

 

[Chris Rebert]

Python is chock-full of identifiers beginning and ending with double
underscores, such as __builtin__, __contains__, and __coerce__.

Using underscores to signal that an identifier is somehow "private"
to an implementation is pretty common in languages other than
Python.  But in these cases the understanding is that the use of
these variables in external code amounts to "going behind the API",
and is therefore unwise.

But as far as I can tell, Python's double-underscore variables are
very much part of Python's API.  E.g., programmers are specifically
instructed to override "double-underscore methods" to achieve
certain functionalities.

Right, but the *users* of the functionality provided by __methods__
typically should not invoke such methods directly.
For example, one should write `a > b`, not `a.__gt__(b)`. The lack of
underscores in just plain `gt` would suggest that it's a normal method
that could/should be called directly. Also, if the underscore
requirement were removed, then people might unknowingly overload an
operator without knowing it.
The double-underscores indicate that the Python interpreter itself
usually is the caller of the method, and as such some level of "magic"
may be associated with it. Other languages have you do the equivalent
of `def +():` or `def operator +()` to override an operator, the
keyword or symbol serving a similar warning that "here be magic". To
avoid adding another keyword and the confusion of having punctuation
as method names, Python uses a different convention, double leading
and trailing underscores.

Cheers,
Chris

 

[r]

....(snip)
Right, but the *users* of the functionality provided by __methods__ ....(snip)
Cheers,
Chris

Yes and Python's way is by-far the proper way to handle such
functionailty. Don't thank god, thank Guido

 

[kj]

The double-underscores indicate that the Python interpreter itself
usually is the caller of the method, and as such some level of "magic"
may be associated with it. Other languages have you do the equivalent
of `def +():` or `def operator +()` to override an operator, the
keyword or symbol serving a similar warning that "here be magic".

In this case, then I hope that some of these __items__ get demoted
to a more mundane level, so that the notion of "magic" doesn't get
trivialized by everyday idioms like:

if __name__ == '__main__':
# etc

There are a few in this category... I figure that they are cases
of "atavistic magic".

I bring this up because I find it quite difficult to explain to my
students (who are complete newcomers to programming) all the
__underscored__ stuff that even rank noobs like them have to deal
with. (Trust me, to most of them your reply to my post would be
as clear as mud.) This suggests to me that there's something a
bit unnatural about some of these __items__.

Anyway, thanks for your post. I see your point.

kynn

 

[David Cournapeau]

In this case, then I hope that some of these __items__ get demoted
to a more mundane level, so that the notion of "magic" doesn't get
trivialized by everyday idioms like:

if __name__ == '__main__':
   # etc

There are a few in this category...  I figure that they are cases
of "atavistic magic".

I bring this up because I find it quite difficult to explain to my
students (who are complete newcomers to programming) all the
__underscored__ stuff that even rank noobs like them have to deal
with.  (Trust me, to most of them your reply to my post would be
as clear as mud.)

Maybe your students do not need to know about it, at least at the
beginning ? I heavily use python, and do not use the underscore
methods so much most of the time, except for __init__,

cheers,

David

 

[kj]

Maybe your students do not need to know about it, at least at the
beginning ? I heavily use python, and do not use the underscore
methods so much most of the time, except for __init__,

Believe me, it's not me who's bringing this stuff up: *they*
specifically ask. That's precisely my point: it is *they* who
somehow feel they can't avoid finding out about this stuff; they
must run into such __arcana__ often enough to cause them to wonder.
If at least some rank beginners (i.e. some of my students) feel
this way, I suggest that some of this alleged __arcana__ should be
demoted to a more mundane everyday status, without the scare-underscores.
E.g. maybe there should be a built-in is_main(), or some such, so
that beginners don't have to venture into the dark underworld of
__name__ and "__main__".

kynn

 

[Zac Burns]

As I understand it, the double underscores is to create a namespace
"reserved for python's internal use". That way python can add more
variables and methods in the future and as long as people respect the
namespace their code will not break with future revisions.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

 

[Steven D'Aprano]

In <[email protected]> Chris Rebert


In this case, then I hope that some of these __items__ get demoted to a
more mundane level, so that the notion of "magic" doesn't get
trivialized by everyday idioms like:

if __name__ == '__main__':
# etc

But that is magic, and just because it's magic doesn't mean it's not
useful every day.

I don't see what's so difficult about telling your students that double
underscore names have special meaning to the Python interpreter. That
doesn't mean you're forbidden from using them, or that you have to use
them, it just means that they have a special meaning to the interpreter,
and you usually don't call them directly.