Should I create each class in its own .py file?
Question:
I’m quite new to Python in general.
I’m aware that I can create multiple classes in the same .py file, but I’m wondering if I should create each class in its own .py file.
In C# for instance, I would have a class that handles all Database interactions. Then another class that had the business rules.
Is this the case in Python?
Answers:
No. Typical Python style is to put related classes in the same module. It may be that a class ends up in a module of its own (especially if it’s a large class), but it should not be a goal in its own right. And when you do, please do not name the module after the class — you’ll just end up confusing yourself and others about which is which.
Probably not. Python files are “modules”. Modules should contain just what code is independently reusable. If that comprises several classes, which is the norm, then that’s perfectly ok.
Each .py file represents a module, so you should keep logical groups of functions, constants and classes together in the same file.
Each class in a .py file will just create epic bloat in your module table, since if you’re only interested in one class you can still
from whatever import SomeClass
Another point worth mentioning, is that if a file grows too large, you can always transform it into a package, making easy to reorganize without breaking the client’s code.
I’ll disagree with the others and say yes. For me, I have had better success putting each class in its own file (module). But there are exceptions so let me explain with an example.
If you have a class Foo, then put it in a file called Foo.py, with the following sections:
- Imports
- This is where you pull in dependencies.
- Examples:
import math, from Bar import *
- Globals
- This is where you define the external interface to your module, which are all of the symbols that are visible outside of this module.
- Example:
__all__ = ['Foo']
- This is also where you can define global variables (bad) and global constants (good). These globals need not be exported; they can be made global merely to simplify the code.
- Example:
PI = 3.14159 means that you can write PI, whereas if you defined it inside class Foo then you would need to write Foo.PI.
- Functions
- This is where you define all top-level functions that are relevant to class Foo, but don’t belong in the class Foo namespace. These are probably rare since classes allow both
@staticmethods and inner classes.
- Example:
def print_foo(foo): print(foo)
- Classes
- Example:
class Foo(object): pass
Sometimes you will want to place more than one class in the same module. You should do this whenever two or more classes are conceptually related to the point where you would almost always use them together and never independently. This is the exception, not the norm. In this case add all of the class names to the __all__ global.
Finally, for every module Foo.py, there should be a corresponding unit test module called testFoo.py.
Yes each class in its own file. Importing even a single class (or function) in a file with multiple classes causes python to execute the definition of all classes in the file. Try this:
manyClass.py
class foo():
print 'a bunch of time consuming work'
class tryme():
print 'try me'
Now type this in the interpreter shell…
from manyClasses import tryme
a bunch of time consuming work
try me
I’m quite new to Python in general.
I’m aware that I can create multiple classes in the same .py file, but I’m wondering if I should create each class in its own .py file.
In C# for instance, I would have a class that handles all Database interactions. Then another class that had the business rules.
Is this the case in Python?
No. Typical Python style is to put related classes in the same module. It may be that a class ends up in a module of its own (especially if it’s a large class), but it should not be a goal in its own right. And when you do, please do not name the module after the class — you’ll just end up confusing yourself and others about which is which.
Probably not. Python files are “modules”. Modules should contain just what code is independently reusable. If that comprises several classes, which is the norm, then that’s perfectly ok.
Each .py file represents a module, so you should keep logical groups of functions, constants and classes together in the same file.
Each class in a .py file will just create epic bloat in your module table, since if you’re only interested in one class you can still
from whatever import SomeClass
Another point worth mentioning, is that if a file grows too large, you can always transform it into a package, making easy to reorganize without breaking the client’s code.
I’ll disagree with the others and say yes. For me, I have had better success putting each class in its own file (module). But there are exceptions so let me explain with an example.
If you have a class Foo, then put it in a file called Foo.py, with the following sections:
- Imports
- This is where you pull in dependencies.
- Examples:
import math,from Bar import *
- Globals
- This is where you define the external interface to your module, which are all of the symbols that are visible outside of this module.
- Example:
__all__ = ['Foo'] - This is also where you can define global variables (bad) and global constants (good). These globals need not be exported; they can be made global merely to simplify the code.
- Example:
PI = 3.14159means that you can writePI, whereas if you defined it inside class Foo then you would need to writeFoo.PI.
- Functions
- This is where you define all top-level functions that are relevant to class Foo, but don’t belong in the class Foo namespace. These are probably rare since classes allow both
@staticmethodsand inner classes. - Example:
def print_foo(foo): print(foo)
- This is where you define all top-level functions that are relevant to class Foo, but don’t belong in the class Foo namespace. These are probably rare since classes allow both
- Classes
- Example:
class Foo(object): pass
- Example:
Sometimes you will want to place more than one class in the same module. You should do this whenever two or more classes are conceptually related to the point where you would almost always use them together and never independently. This is the exception, not the norm. In this case add all of the class names to the __all__ global.
Finally, for every module Foo.py, there should be a corresponding unit test module called testFoo.py.
Yes each class in its own file. Importing even a single class (or function) in a file with multiple classes causes python to execute the definition of all classes in the file. Try this:
manyClass.py
class foo():
print 'a bunch of time consuming work'
class tryme():
print 'try me'
Now type this in the interpreter shell…
from manyClasses import tryme
a bunch of time consuming work
try me