In Python, "privacy" depends on "consenting adults'" levels of agreement - you can't force it. A single leading underscore means you're not supposed to access it "from the outside" -- two leading underscores (w/o trailing underscores) carry the message even more forcefully... but, in the end, it still depends on social convention and consensus: Python's introspection is forceful enough that you can't handcuff every other programmer in the world to respect your wishes.

((Btw, though it's a closely held secret, much the same holds for C++: with most compilers, a simple #define private public line before #includeing your .h file is all it takes for wily coders to make hash of your "privacy"...!-))

This depends on the relation between the task of those methods and the purpose of the object.

If your object is a report generator and uses a lot of utility functions to justify, inflect and tabulate strings, then those methods have little to do with the purpose of the object. Generating records involves justifying lines of text, but such routines can be used for many other purposes as well, so they should live outside the class - in fact, probably within a general string-handling module.

If the methods are strongly connected to the state and member variables of the object, then they should probably be private member functions. A good heuristic is that you end up always passing some of your own member variables to a function, that function should probably be a member function itself.

There is no hard rule on what should be marked as private.

As a general guideline, you should at least mark everything that is not meant to be used from outside the module (or class) as private, but you can extend that, at your discretion and based on conventions within your team, up to everything that is currently not used outside the module/class.

Marking functions that might be useful for use from other modules as private has both benefits and drawbacks. The benefit is that you don't have to worry about breaking an API when you change the signature of the function. The drawback is that if another module needs the same functionality, either they will duplicate the function, or you need to do some rework to make the function public.

The name scrambling is used to ensure that subclasses don't accidentally override the private methods and attributes of their superclasses. It's not designed to prevent deliberate access from outside.

For example:

>>> class Foo(object):
...     def __init__(self):
...         self.__baz = 42
...     def foo(self):
...         print self.__baz
...     
>>> class Bar(Foo):
...     def __init__(self):
...         super(Bar, self).__init__()
...         self.__baz = 21
...     def bar(self):
...         print self.__baz
...
>>> x = Bar()
>>> x.foo()
42
>>> x.bar()
21
>>> print x.__dict__
{'_Bar__baz': 21, '_Foo__baz': 42}

Of course, it breaks down if two different classes have the same name.

To clarify:

• If a name starts with one underscore, it is 'protected'.
• If a name starts with two underscores but does not end with two underscores, it is 'private'.

'Protected' is just a convention, but syntax checkers do nag about accessing them outside the class hierarchy.

'Private' is implemented by name mangling, so that the element can only be used from within the class where it was defined. The two underscores are replaced with _<name of class>__. There are tricks to circumvent this...

In the example below, pylint does not warn me for using _func inside the Test class, but I do get a warning (W0212) at the last line. Did you forget to define the protected function in the base class?

class Test(object):
    def _func(self):
        raise NotImplementedError()

    def fun(self):
        self._func()
  
class Demo(Test):
    def _func(self):
        print 'Hi'

t = Demo()
t._func()

I prefix private modules with an underscore to communicate the intent to the user. In your case, this would be mypack._mod_b

This is in the same spirit (but not completely analogous to) the PEP8 recommendation to name C-extension modules with a leading underscore when it’s wrapped by a Python module; i.e., _socket and socket.

Use a single underscore prefix:

class _Internal:
    ...

This is the official Python convention for 'internal' symbols; from module import * does not import underscore-prefixed objects.

Reference to the single-underscore convention in the Python 2 and Python 3 documentation.

True private methods - those that can't be seen or used from outside of a class - do not exist in Python. What we have are conventions that are merely suggestions to not touch things you shouldn't.

The closest you get to privacy is name mangling. An attribute of MyClass named __some_attr will just be renamed to _MyClass__some_attr internally, making it slightly awkward to reference it from outside the class. This is seldom used. What most people do is simply prefix a single underscore (_attr) as a notation that something should not be relied upon & is not part of the public interface.

Using double underscores before and after the identifier, while not prohibited, is considered reserved for internal language details (like 'magic' methods). You shouldn't go around coming up with new __attr__s (unless you're hacking on the interpreter).