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]

Matias Jansson wrote:

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]

Matias Jansson wrote:

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]

Matias Jansson wrote:

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]

On Dec 12, 8:29 am, "Matias Jansson"
<matias.jans... @carmenconsulti ng.comwrote:

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]

Isaac Rodriguez wrote:

>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.

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
cv*********@mvi sta.com
Build and Release
MontaVista Software

[Gabriel Genellina]

On 12 dic, 16:17, "Isaac Rodriguez" <isaac.rodrig.. [e-mail]>
wrote:

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.

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?)

--
Gabriel Genellina