Are multiple classes in a single file recommended?
Question:
Possible Duplicate:
How many Python classes should I put in one file?
Coming from a C++ background I’ve grown accustomed to organizing my classes such that, for the most part, there’s a 1:1 ratio between classes and files. By making it so that a single file contains a single class I find the code more navigable. As I introduce myself to Python I’m finding lots of examples where a single file contains multiple classes. Is that the recommended way of doing things in Python? If so, why?
Am I missing this convention in the PEP8?
Answers:
In python, class can also be used for small tasks (just for grouping etc). maintaining a 1:1 relation would result in having too many files with small or little functionality.
There’s a mantra, “flat is better than nested,” that generally discourages an overuse of hierarchy. I’m not sure there’s any hard and fast rules as to when you want to create a new module — for the most part, people just use their discretion to group logically related functionality (classes and functions that pertain to a particular problem domain).
Good thread from the Python mailing list, and a quote by Fredrik Lundh:
even more important is that in Python,
you don’t use classes for every-
thing; if you need factories,
singletons, multiple ways to create
objects, polymorphic helpers, etc, you
use plain functions, not classes or
static methods.
once you’ve gotten over the “it’s all
classes”, use modules to organize
things in a way that makes sense to
the code that uses your components.
make the import statements look good.
There is no specific convention for this – do whatever makes your code the most readable and maintainable.
Here are some possible reasons:
- Python is not exclusively class-based – the natural unit of code decomposition in Python is the module. Modules are just as likely to contain functions (which are first-class objects in Python) as classes. In Java, the unit of decomposition is the class. Hence, Python has one module=one file, and Java has one (public) class=one file.
- Python is much more expressive than Java, and if you restrict yourself to one class per file (which Python does not prevent you from doing) you will end up with lots of very small files – more to keep track of with very little benefit.
An example of roughly equivalent functionality: Java’s log4j => a couple of dozen files, ~8000 SLOC. Python logging => 3 files, ~ 2800 SLOC.
the book Expert Python Programming has something related discussion
Chapter 4: Choosing Good Names:”Building the Namespace Tree” and “Splitting the Code”
My line crude summary: collect some related class to one module(source file),and
collect some related module to one package, is helpful for code maintain.
A good example of not having seperate files for each class might be the models.py file within a django app. Each django app may have a handful of classes that are related to that app, and putting them into individual files just makes more work.
Similarly, having each view in a different file again is likely to be counterproductive.
Possible Duplicate:
How many Python classes should I put in one file?
Coming from a C++ background I’ve grown accustomed to organizing my classes such that, for the most part, there’s a 1:1 ratio between classes and files. By making it so that a single file contains a single class I find the code more navigable. As I introduce myself to Python I’m finding lots of examples where a single file contains multiple classes. Is that the recommended way of doing things in Python? If so, why?
Am I missing this convention in the PEP8?
In python, class can also be used for small tasks (just for grouping etc). maintaining a 1:1 relation would result in having too many files with small or little functionality.
There’s a mantra, “flat is better than nested,” that generally discourages an overuse of hierarchy. I’m not sure there’s any hard and fast rules as to when you want to create a new module — for the most part, people just use their discretion to group logically related functionality (classes and functions that pertain to a particular problem domain).
Good thread from the Python mailing list, and a quote by Fredrik Lundh:
even more important is that in Python,
you don’t use classes for every-
thing; if you need factories,
singletons, multiple ways to create
objects, polymorphic helpers, etc, you
use plain functions, not classes or
static methods.once you’ve gotten over the “it’s all
classes”, use modules to organize
things in a way that makes sense to
the code that uses your components.
make the import statements look good.
There is no specific convention for this – do whatever makes your code the most readable and maintainable.
Here are some possible reasons:
- Python is not exclusively class-based – the natural unit of code decomposition in Python is the module. Modules are just as likely to contain functions (which are first-class objects in Python) as classes. In Java, the unit of decomposition is the class. Hence, Python has one module=one file, and Java has one (public) class=one file.
- Python is much more expressive than Java, and if you restrict yourself to one class per file (which Python does not prevent you from doing) you will end up with lots of very small files – more to keep track of with very little benefit.
An example of roughly equivalent functionality: Java’s log4j => a couple of dozen files, ~8000 SLOC. Python logging => 3 files, ~ 2800 SLOC.
the book Expert Python Programming has something related discussion
Chapter 4: Choosing Good Names:”Building the Namespace Tree” and “Splitting the Code”
My line crude summary: collect some related class to one module(source file),and
collect some related module to one package, is helpful for code maintain.
A good example of not having seperate files for each class might be the models.py file within a django app. Each django app may have a handful of classes that are related to that app, and putting them into individual files just makes more work.
Similarly, having each view in a different file again is likely to be counterproductive.