This is an argument in favor of using single underscore for declaring internal attributes (methods or variables).
Use one leading underscore only for non-public methods and instance variables.
...
Even with __all__ set appropriately, internal interfaces
(packages, modules, classes, functions, attributes or other names)
should still be prefixed with a single leading underscore.
https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
To avoid name clashes with subclasses, use two leading underscores to invoke
Python's name mangling rules.
https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables
Python's runtime does not restrict access to such members, the mangling only
prevents name collisions if a derived class defines a member with the same name.
https://en.wikipedia.org/wiki/Name_mangling#Python
Or https://softwareengineering.stackexchange.com/a/229807 Or http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#naming
This whole stackoverflow response is great: http://stackoverflow.com/a/7456865
For a Pythonista, encapsulation is not the inability of seeing internals of classes,
but the possibility of avoiding to look at it. I mean, encapsulation is the property
of a component which allows it to be used without the user being concerned about the
internal details. If you can use a component without bothering yourself about its
implementation, then it is encapsulated (in the opinion of a Python programmer).
The Google Python style guide is a great addition to PEP8. It adds some very legitimate guidelines on PEP8 inaccuracies to keep a codebase readable by everyone and maintainable at scale.
Basing our Python Style on Google Python style guide is the best thing to do.
It means:
- We are adopting the generally known breed of Python, the one everyone knows.
- That our Python won't look different that most of the libraries we use.
- We can hire Python devs and we won't need to teach them MyCompanyPython
👍