44

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?

Alastair Pitts
  • 19,423
  • 9
  • 68
  • 97
Sergio Tapia
  • 40,006
  • 76
  • 183
  • 254

6 Answers6

36

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.

Thomas Wouters
  • 130,178
  • 23
  • 148
  • 122
  • 8
    Coming from Java I had this same question, boy was I confused for a while. :-) – snarkyname77 Jan 20 '10 at 00:54
  • Interestingly, PyDev gives you the option to do just that. – Uri Jan 20 '10 at 14:54
  • If you import a class from a file with multiple classes, wouldn't the interpreter execute all classes in that file? – Claudiu Creanga Jun 08 '17 at 14:09
  • It depends on what you mean by "execute". Yes, the 'class' statements appearing in the global namespace are executed. That's how classes are defined, by executing their 'class' statement. It does not instantiate them, and if class definition is prohibitively expensive, you have more to worry about than just how many classes are in a module. – Thomas Wouters Jun 12 '17 at 13:14
8

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
richo
  • 8,717
  • 3
  • 29
  • 47
  • 8
    Python style usually uses `lowercase` for module names and `CapWords` for class names: http://www.python.org/dev/peps/pep-0008/ – Greg Hewgill Jan 19 '10 at 23:56
  • 1
    Sometimes styles are silly. If you have a class Foo, go ahead and put it in module Foo.py. Why would you put it in lowercase foo.py? So you can write `from foo import Foo`? By writing `__all__ = ['Foo']` in the module, you can then type `from foo import *` or `from Foo import *` and there will be no confusion. So lowercase module names are silly if they just contain one class. – Nathan Farrington Jan 12 '11 at 18:31
  • https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds – Tarynn Jan 12 '22 at 22:07
7

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:

  1. Imports
    • This is where you pull in dependencies.
    • Examples: import math, from Bar import *
  2. 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.
  3. 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)
  4. 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.

Nathan Farrington
  • 1,890
  • 1
  • 17
  • 27
  • Should the unit test module be an exact copy of the module? What else would you put in it? – will Jan 21 '22 at 20:48
3

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.

Kenan Banks
  • 207,056
  • 34
  • 155
  • 173
3

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.

Bruno Oliveira
  • 13,694
  • 5
  • 43
  • 41
  • 2
    A package is simply multiple files (multiple modules). So your answer is basically saying that yes, each class should go in its own file (module) when the amount of code gets too large. – Nathan Farrington Jan 12 '11 at 18:27
1

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

Jim Paul
  • 179
  • 1
  • 4
  • You don't generally put time-consuming work like that straight in the class definition. They'd go inside functions which won't get executed immediately. – alexia Aug 18 '22 at 08:34