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?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
aretor
  • 2,379
  • 2
  • 22
  • 38
  • 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. – Daniel Roseman Jan 20 '17 at 10:46

2 Answers2

22

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.

bruno desthuilliers
  • 75,974
  • 6
  • 88
  • 118
  • 1
    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 Jan 20 '17 at 14:59
  • @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. – bruno desthuilliers Jan 20 '17 at 15:16
  • 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. – Marius Mucenicu Jun 04 '19 at 18:29
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.

kouty
  • 320
  • 8
  • 17
Dmitry
  • 2,026
  • 1
  • 18
  • 22