Python doesn't have the concept of private methods or attributes. It's all about how you implement your class. But you can use pseudo-private variables (name mangling); any variable preceded by __(two underscores) becomes a pseudo-private variable.

From the documentation:

Since there is a valid use-case for class-private members (namely to avoid name clashes of names with names defined by subclasses), there is limited support for such a mechanism, called name mangling. 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, as long as it occurs within the definition of a class.

class A:
    def __private(self):
       pass

So __private now actually becomes _A__private.

Example of a static method:

>>> class A:
...     @staticmethod         # Not required in Python 3.x
...     def __private():
...         print 'hello'
...
>>> A._A__private()
hello

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.

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).

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.