What Is the Naming Convention in Python For Variable and Function

What is the naming convention in Python for variable and function?

See Python PEP 8: Function and Variable Names:

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

Variable naming conventions for function variables

Since the two are parameters within the scope of two different functions, it is completely fine to name them the same. However, since file is a builtin in Python, I would suggest to name it differently or to add an underscore at the end of the name.

Python naming convention for variables that are functions

Does Python have a naming convention for variables that are functions?

No it does not, functions are first class objects in Python. Pass the function name as you would access it for calling.

For example:

def foo():
    pass

foo() # calling

another_function(foo) # passing foo

One of the hardest things in programming is getting naming right, however. I would certainly use a more descriptive name, probably one that is a verb. For example:

def do_nothing():
    pass

EDIT: Same deal, but there's nothing to stop you from using _fn as a suffix if it makes your code clearer:

def foo_a():
    print 'a'

def foo_b():
    print 'b'

funcs = {'a': foo_a, 'b': foo_b}

# dynamically select function based on some key
key = 'a'
foo_fn = funcs[key]

foo_fn() # calling
another_function(foo_fn) # passing

What does the Python naming convention with single/double underscore before a function mean?

Usually, this kind of design is used in two related (but nearly-opposite) patterns, which I don't know the "design patterns" names for. (I think they both include "engine", and one includes "template", if that helps.)

---

For the first, the idea is to allow a subclass to override the public catch method to, say, add a bit of extra work before or after the core implementation, but still call the _catch method to do most of the work. For example:

Class Pokemon(object):
     def __init__(self, name):
          self.name = name

     def _catch(self, pokeball):
         ''' actual implementation here'''
         # hundreds of lines of complex code
         print(pokeball)
         return pokeball

     def catch(self, pokeball):
         print('Gotta catch em all')
         return self._catch(pokeball)

class Pikachu(Pokemon):
     def catch(self, pokeball):
         print('Pikachu')
         return self._catch(pokeball)

This allows Pikachu to override the "non-core" part of the implementation, which is only a few lines, without overriding the "core" part, which is hundreds of lines.

This pattern isn't nearly as common in Python as it is in, say, Java, but it does sometimes make sense.

---

For the other, the idea is to have the base class break the implementation up into separate pieces, each of which can be overridden by the subclass without having to replace everything else. For example:

class Pokemen(object):
    def catch(self, pokeball):
        self._wake_up()
        if not self._check_ready() return False
        try:
            return self._catch(pokeball)
        except SillyError:
            return False
        finally:
            self.consider_sleeping()

---

So, why use a leading underscore?

The leading single underscore means "private by convention". For a method name, in particular,^* it's a hint to the human reader that something is not part of the API. Anyone who wants to use a Pokemon object should not call _catch on it, because that method is an implementation detail—it may change or even go away in future versions, it may make assumptions about the object's state that aren't guaranteed to always be true, etc. But catch should always be safe to call.

Often this is a good match for something that you'd make a protected method in Java or C++, which is exactly what you'd use for both of these design patterns in those languages, even though it doesn't really mean the same thing.

---

A leading double underscore (without a trailing double underscore) means something different. In a method name or other attribute, it means the name should be "mangled" so that it's harder for a subclass or superclass to accidentally call it, or override it, when it intended to define and use its own private name instead.

Often, this is a good match for something that you'd make a private method or member in Java or C++, but it's even farther from that than a single underscore is from protected.

---

_{* In a few other places, it actually does have a tiny bit more meaning. For example, a module global with a leading underscore will be skipped by from mod import * if you didn't specify an __all__ in mod.}

---

Related Topics