13

Ok I think I have understood the use of one and two heading underscores in Python.

Correct me if I am wrong,

  1. In the case of one underscore, the underscore prevents the from X import * statement to import this kind of variables.

  2. In the case of two underscores, the variable's name is prepended with the name of the class it belongs to allow a higher level of "privateness".

My question now is: why not use two underscores only? In which cases one underscore is preferred (or needed) over two underscores?

Improve this question
1
  • 2
    Er, because they do different things, as you yourself described? The question "why use two underscores at all" might make more sense, but I can't understand what you're asking. Commented Jan 20, 2017 at 10:46

2 Answers 2

Reset to default
24

Short answer: use a single leading underscore unless you have a really compelling reason to do otherwise (and even then think twice).

Long answer:

One underscore means "this is an implementation detail" (attribute, method, function, whatever), and is the Python equivalent of "protected" in Java. This is what you should use for names that are not part of your class / module / package public API. It's a naming convention only (well mostly - star imports will ignore them, but you're not doing star imports anywhere else than in your Python shell are you ?) so it won't prevent anyone to access this name, but then they're on their own if anything breaks (see this as a "warranty void if unsealed" kind of mention).

Two underscores triggers a name mangling mechanism. There are very few valid reason to use this - actually there's only one I can think of (and which is documented): protecting a name from being accidentally overridden in the context of a complex framework's internals. As an example there might be about half a dozen or less instances of this naming scheme in the whole django codebase (mostly in the django.utils.functional package).

As far as I'm concerned I must have use this feature perhaps thrice in 15+ years, and even then I'm still not sure I really needed it.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I understand your point but in the case of private attributes in a class, wouldn't be better to use a double underscore? To me, they provide better way to make attributes private, rather then one underscore attributes.
@AreTor what's important is to clearly mark what's public and what's not - not to make attributes "private". Actually one of the main differences between a seasoned OO programmer and a novice one is that the first one will make most of it's members protected, and very very seldom make one of them truly private, because there are very few reason to block child classes from accessing one of their own attributes. Most of the times if your base class needs a distinct namespace for a set of implementation attributes (and methods using them) then this is better delegated to another object.
excellent comparison to Java's protected... I hate it when people associate the single leading _ to private. Ignoring the fact that, in Python, nothing's actually private. We're talking analogies here. The single _ would be Java's protected, and the double __ would be Java's private in an analogy.
6

Look at documentation.

1. Single Underscore

From PEP-8:

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

2. Double Underscore:

From the Python tutorial:

Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped. This mangling is done without regard to the syntactic position of the identifier, so it can be used to define class-private instance and class variables, methods, variables stored in globals, and even variables stored in instances. private to this class on instances of other classes. Name mangling is intended to give classes an easy way to define “private” instance variables and methods, without having to worry about instance variables defined by derived classes, or mucking with instance variables by code outside the class. Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.