One module per class, bad idea?

[Matias Jansson]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

 

[billie]

would it be a bad idea to have a guideline

in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

Yes, it would be a bad idea. =)

 

[Fredrik Lundh]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.

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.

</F>

 

[Fuzzyman]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

It's not a bad general guideline.

We try and use one class per file unless they are really trivial or
tightly coupled to another.

It allows you to be very specific in the naming of files and isolate
functionality.

We also have files with 'helper functions', which often have several
functions.

Fuzzyman
http://www.voidspace.org.uk/index2.shtml

 

[Andy Dingley]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure.

Don't confuse packages and files. Java commonly splits a package
across many files, Python binds a module to a single file. If you see
"Java package" as more comparable to "Python module" then the
difference in how many classes are in a file becomes unimportant.

Java also puts many classes in the same source file, if they're tightly
coupled (e.g. Swing UI). It spits them out into separate .class files
though.

 

[Paddy]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

Hi,
This is one of the cases where Java and C# common practice diverge from
Pythons.
You might try looking at the source to some of the standard modules to
see how things are done in Python.

- Paddy.

 

[Isaac Rodriguez]

Yes, it would be a bad idea. =)

Saying it is a bad idea and not explaining why will not help anyone. I
would like you to elaborate on why it is a bad idea to have one file
per class.

Thanks,

- Isaac.

 

[Isaac Rodriguez]

make the import statements look good.

You can still make your import statements look good and have one class
per file, that's one of the __init__.py wonderful features.

Also, C++ support stand alone functions and the rule is to organize
classes and their interface (functions that operate in objects of the
class are considered part of the interface) in their own module.

I will like to understand why this will not be a good idea for python,
other than to make beautiful import statements that is.

Thanks,

- Isaac.

 

[Carl J. Van Arsdall]

Saying it is a bad idea and not explaining why will not help anyone. I
would like you to elaborate on why it is a bad idea to have one file
per class.

A module per class makes a lot of sense in some cases, or rather, make
your module your class (look at the singleton pattern). I actually like
to structure all of my code like this, it helps me keep things organized
and separated. I guess i'm not sure why it would ever be a really bad
idea, maybe if you had really small classes?

-c


--

Carl J. Van Arsdall
(e-mail address removed)
Build and Release
MontaVista Software

 

[Gabriel Genellina]

would like you to elaborate on why it is a bad idea to have one file
per class.

The HyperText package (http://dustman.net/andy/python/HyperText) has a
lot of classes (about 90 in HTML40.py); one class per HTML tag. Most of
them are oneliners with "pass" alone. All are public. It would be
nonsense to split them on one file per class just because you have a
rule that says so.
On the other hand, it would be nonsense too to mix a bunch of unrelated
classes all inside a single module, just because you can do that.
Common sense is hard to measure, but required as any other programming
skills. (Anyone knows the story of Epaminondas and his auntie?)

 

[Carl Banks]

A module per class makes a lot of sense in some cases, or rather, make
your module your class (look at the singleton pattern). I actually like
to structure all of my code like this, it helps me keep things organized
and separated.

I don't understand. Are you saying you organize your code to be a
bunch of modules masquerading as singleton classes? (When I was a
young'n, we called that "procedure oriented programming"

I guess i'm not sure why it would ever be a really bad
idea, maybe if you had really small classes?

Or maybe you have really big classes.

The potential problem with one module per class is one of missed
opportunity: namely the missed opportunity for a higher-level
organization.

Classes are rarely, probably never, a good way to organize code at the
highest levels. It's better to organize code into subsystems of some
sort. It's very rare that each class is an independent subsystem unto
itself; most high-level subsystems would encompass many classes (as
well as other code). When you strictly obey a one class per module
rule, you lose the possibility of using the module as a means of
organizing subsystems (and subsubsystems, and so on).

Now, I think this is the best way to use modules, but you don't need to
use modules to do get higher-level organization; you could use packages
instead. It's a pain if you're working on two different classes in the
same system you have to keep switching files; but I guess some people
prefer to switch files rather than to scroll for some reason.

I'd say as long as you use package system, and not just a flat
modulespace, it's not fundamentally disorganized to use a one class per
module rule. In the end, it probably comes down to what you prefer,
but I think most people would prefer not to obey a one class per module
rule.


Carl Banks

 

[Carl Banks]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

One class per module is like having a filing system where you limit
yourself to one piece of paper per file.

(I think it's just convention, really. You don't have to use one class
per module in Python, and given that freedom, most Python programmers
didn't.)


Carl Banks

 

[Carl J. Van Arsdall]

I don't understand. Are you saying you organize your code to be a
bunch of modules masquerading as singleton classes? (When I was a
young'n, we called that "procedure oriented programming"

Well, when you have a class you want instantiated once and only once
(i.e. a singleton) you can do it in python really easily vs a langauge
like C++ (and i'll explain).

So, in C++ when you want to create a singleton you need to go through a
little bit of work to make sure that the constructor (this might be a
naive method, but i never claimed to be elite) checks to make sure
another class of the same type has never been created. Singletons get
more elaborate than this, but I'm just trying to illustrate a point.

In python a model can be treated as a singleton class. Think of a
module's global variables as the variables of the class and the function
in the module that operate on those variables as the class' methods.
When you instantiate a module you get one and only one, the global
variables more or less stay static throughout your execution (or at
least, the way I use it). So say you have a module that acts as a
centralized ressource (how about some piece of IO)? In a language like
java you will have one and only one interface to that IO (i mean it
depends on the IO, bear with me its just to illustrate a point), if a
user tries to make a new class it will just return a reference to the
singleton class that already exists. So python modules are really
useful for this type of construct.

I'm not saying you want to make all of your modules singleton classes,
but its kind of a hidden benefit of modules. You get a singleton and
don't have to really do any extra work Again, i've never done
anything incredibly complex, but i've found this useful a couple of times.

Or maybe you have really big classes.

The potential problem with one module per class is one of missed
opportunity: namely the missed opportunity for a higher-level
organization.

Classes are rarely, probably never, a good way to organize code at the
highest levels. It's better to organize code into subsystems of some
sort. It's very rare that each class is an independent subsystem unto
itself; most high-level subsystems would encompass many classes (as
well as other code). When you strictly obey a one class per module
rule, you lose the possibility of using the module as a means of
organizing subsystems (and subsubsystems, and so on).

Now, I think this is the best way to use modules, but you don't need to
use modules to do get higher-level organization; you could use packages
instead. It's a pain if you're working on two different classes in the
same system you have to keep switching files; but I guess some people
prefer to switch files rather than to scroll for some reason.

Yea, you have a good point. I don't have a lot of experience with
packages, but I've also never written anything so large that i've had
more than 5-10 modules. I'll spend some time looking into it, thanks!

I'd say as long as you use package system, and not just a flat
modulespace, it's not fundamentally disorganized to use a one class per
module rule. In the end, it probably comes down to what you prefer,
but I think most people would prefer not to obey a one class per module
rule.


Carl Banks

-Carl V.

--

Carl J. Van Arsdall
(e-mail address removed)
Build and Release
MontaVista Software

 

[Carl Banks]

Well, when you have a class you want instantiated once and only once
(i.e. a singleton) you can do it in python really easily vs a langauge
like C++ (and i'll explain).

[snip]

I understand what you're saying. It's a good technique to use
sometimes; I've done it myself. (I've even gone so far as to write
decorator to pass in the module as "self".) However, I'm quite sure
the OP was talking about real classes, and whether we should limit
ourselves to one real class per module.


[snip]

Yea, you have a good point. I don't have a lot of experience with
packages, but I've also never written anything so large that i've had
more than 5-10 modules. I'll spend some time looking into it, thanks!

A ha!

I should note that in my reply I was not thinking about small programs.
For a small program each class could very well be subsystem unto
itself, so one class per module would be ok.


Carl Banks

 

[Paddy]

I will like to understand why this will not be a good idea for python,
other than to make beautiful import statements that is.

Thanks,

- Isaac.

Read more Python source Isaac. especially for modules you like to use.
That way you see how others use modules and can decide for yourself.
As others have noted, people might not consider it good style if you
put lots of related, very small, classes in individual files. You can,
but it is not mandated by the interpreter.

- Paddy.

 

[billie]

Saying it is a bad idea and not explaining why will not help anyone. I
would like you to elaborate on why it is a bad idea to have one file
per class.

Thanks,

- Isaac.

Because it's just a useless limitation.
Python lets you the freedom to decide if using one class per file or a
lot of classes per file and this, imho, is a great advantage of Python
other Java.
Personally I like to have the possibility to include multiple classes
in one module if I need them. Obviously I'll hardly mix classes having
different tasks in the same .py file.
If you come from Java feel free to use the Java approach.

 

[mystilleef]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

It's a good idea. And I encourage it in my project. It makes sense for
us
because we document classes and methods copiously. However, use
whatever
works for your project.

 

[Jorgen Grahn]

I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guideline
in your project that promotes a one class per file structure (assuming most
of the programmers a background similar to mine)?

Never mind their background; think about their future ;-)

Besides, I think you have plenty of C and C++ hackers around, too.

Seriously, I agree with what F Lundh wrote elsewhere in the thread; no need
to repeat it here.

/Jorgen

 

[Kent Johnson]

Now, I think this is the best way to use modules, but you don't need to
use modules to do get higher-level organization; you could use packages
instead. It's a pain if you're working on two different classes in the
same system you have to keep switching files; but I guess some people
prefer to switch files rather than to scroll for some reason.

That would be me. I strongly prefer to switch files rather than scroll.
I use an editor that makes it easy to switch files. For me it is much
easier to switch between files than to scroll between two parts of a
file, and I don't lose my place when I switch back. I like to be able to
see things side by side.

So I do tend to put classes in separate modules. Not always - when two
or more classes are closely related or a class has one or more helper
classes they may share a module - but in general my major classes are
each to a module.

It does make the imports look funny - I tend to give the module the same
name as the class, Java style, so I have
from foo.bar.MyClass import MyClass
but that is a minor point IMO.

Kent

 

[Carl Banks]

That would be me. I strongly prefer to switch files rather than scroll.
I use an editor that makes it easy to switch files. For me it is much
easier to switch between files than to scroll between two parts of a
file, and I don't lose my place when I switch back. I like to be able to
see things side by side.

Man, I don't know you do it.

Say I'm sitting there concentrating on programming something, and I see
that I'll have to make a change in another file. All of a sudden, I
have to recall some filename out of thin air. Totally breaks my train
of thought, sometimes I space out trying to think of it because I have
to cold-start an entirely different part of my brain. It's less of a
mental distraction to just scroll.

I'm in the habit of changing things as soon as the need arises. If I'm
editing A and I see that I'll have to make a change in B, I stop
editing A, change B, then come back to A. For me, it results in MUCH
fewer forgotten changes (YMMV). But it also means a lot of switching.
Consequently, trying to minimize distraction during switches is
important to me. Maybe it isn't if you switch less frequently, and
rarely while in the middle of somthing. I wonder if there's any
correlation between how often one switches location, and preferrence
(tolerance) for file size. I bet the more often one switches location,
the more likely they are to prefer larger files.

(BTW, any decent editor will let you view different positions of the
same file side-by-side.)

So I do tend to put classes in separate modules. Not always - when two
or more classes are closely related or a class has one or more helper
classes they may share a module - but in general my major classes are
each to a module.

It does make the imports look funny - I tend to give the module the same
name as the class, Java style, so I have
from foo.bar.MyClass import MyClass
but that is a minor point IMO.

I'd consider using all lowercase for the module. Of course it doesn't
make sense to come up with a unique name for modules when they're
mostly one-to-one with classes, but it's still nice to give users a
clue whether they object they're looking at is a class or a module.


Carl Banks