Suppose I have a class C with a method f() which is meant to be used only within C's implementation, but which should be overridden by C's subclasses.

Is it reasonable, or "pythonic", to consider it private, i.e. to name it _f() rather than f()?

In other words would you distinguish the interface provided to subclasses from the interface provided to code outside the inheritance hierarchy?

4 Answers 4


Pythonically speaking, you should utilize the Abstract Base Class module to implement this functionality.


from abc import ABCMeta, abstractmethod

class MyBaseClass(object):

    __metaclass__ = ABCMeta

    def f(self, *args):
        #"Public" method (accessible from outside of class instance)

    def _f(self, *args):
        #"Private" method (should only be accessed from with instance)

Then this is what happens when you attempt to instantiate a subclass of MyBaseClass without overriding _f():

>>> my_base_class = MyBaseClass()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class MyBaseClass with abstract methods _f
>>> class B(MyBaseClass):
...     pass
>>> b = B()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class B with abstract methods _f
>>> class B(MyBaseClass):
...     def _f(self):
...             print "foo"
>>> b=B()
>>> b._f()

Note that there are no programmatically "private" methods in Python. That being said, a single underscore before the name (_f()) is used to signify that the method should only be accessed internally.


Your question isn't really specific to python but could be applied to many OO languages like C++ or C#. I haven't yet come across a hard rule but same thought did occur to me from time to time.

So what follows is my opinion:

  • Private method - what only class C should know about and/or use. No one else
  • Protected methods - what deriving classes should know about and/or use.
  • Public methods - what external code should know about and/or use.

So in your example, I would make the function protected but in documentation of class C make it very explicit that deriving classes are not intended to call this function directly. Rather they should implement it and let the base class decide when it is appropriate to call it.

In other words, you expect deriving class to provide implementation. So at this point, nothing is stopping the person coding that class from calling that code. Even if you manage to somehow "mark it private", since that person wrote that code once, he'll write it again, or find another way to run it if that's what he/she really wants to do.

As far as what's pythonic. I'm not a python expert, but I believe this is the language convention:

  • no underscore prefix (i.e. f() ) = public function
  • double underscore (i.e. __f() ) = private function
  • single underscore (i.e. _f() ) = internal use function

Python relies heavily on convention rather than language to keep people from accessing private date. Nothing is really hidden, but when you prefix function name with __, the interpreter will "mangle" that function name. The reason it does that is to discourage (not prevent) people from writing client code that calls private functions:

c = C()

... will result in interpreter telling you that the function doesn't exist. But if someone really wants to call your private function, they'll just write:

c._C__foo()  # mangled name

I wouldn't recommend using private functions in python for protected ones. It seems the language really intended __ to signal to the outside world, including deriving classes: "don't touch".

In your case, I would use a single _ to signal that the function is not for public/external consumption but rather should only be used, or overridden by someone who has enough knowledge about the class (i.e. presumably implementer of the deriving class is more knowledgeable about some internal details than someone writing client code).

Few sources that mention the use of __ (double-underscore) for private symbols:

  • 3
    As a python programmer, I would avoid naming methods with a double underscore. In Python, there is really no such thing as a private method, and a single underscore is used to signify that the programmer is strongly discouraged from accessing that method from outside the class/instance. The double underscore convention should be reserved for the builtin methods of the class and for name mangling purposes. Aug 25, 2013 at 19:04
  • @JoelCornett: Section 9.6 from official documentation mentions single underscore prefix for "non-public" members but they also mention that double-underscore would do name mangling which is intended for private members as the mangling, while not truly hiding, will prevent symbols from clashing with those in deriving classes. Not saying you are wrong, and official docs are somewhat vague as I read them, but I'll add more links to my answer that suggest the use of double-underscore for private members
    – DXM
    Aug 25, 2013 at 23:00
  • Standard C++ library has many pure virtual methods and all of them are private, not protected. Many of them are called publicly through thin wrapper, but they are still private.
    – Jan Hudec
    Aug 26, 2013 at 8:14
  • @DXM: Right, but such usage is strongly discouraged. stackoverflow.com/questions/7456807/… Aug 26, 2013 at 12:21

Since your question is about what is the "pythonic" way, see the naming section of Code Like a Pythonista in which the author says "But try to avoid the __private form. I never use it." and more importantly:

It's better to use the single-leading-underscore convention, _internal.  This isn't name mangled at all; it just indicates to others to "be careful with this, it's an internal implementation detail; don't touch it if you don't fully understand it". It's only a convention though.

In other words, the very concept of "private" is not pythonic. In addition, the single underscore _internal notation is explicitly there to special purpose internal structure you describe.


I can't speak for the "pythonic" way, as I am not familiar with Python.

In languages like C++, C# and Java, there is an explicit provision to distinguish three kinds of members:

  • private for the members that are only accessible to the class itself
  • public for the members that are accessible to the world
  • protected for the members that are accessible to the descendants

In C++, there is even an idiom to use private virtual functions (and override them in a derived class). See this question on SO for more details.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.