Why NOT only one class per file?

[Chris Lasher]

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.

I tried to rationalize this Python idiom by claiming a file--a single
module--makes for a great container of code which is logically tied
together, such as a class and its subclasses. He posited that
directories (packages) can tie the files together just as well, and by
having the classes as separate files, he can "diff" them to see how
they differ, something he wouldn't be able to do with the code all in
one file.

I also offered that having related classes under one file gives more
direct access to those classes, e.g.:

----------------------------------
file: foo.py
===
class Bar(object):
pass
===

file demo1.py
===
import foo

barinstance = foo.Bar()
===
----------------------------------

versus

----------------------------------
file: foopkg/bar.py
===
class Bar(object):
pass
===

file: demo2.py
===
import foopkg.bar

barinstance = foopkg.bar.Bar( )
===
----------------------------------

He doesn't find my arguments convincing, so I thought I'd ask here to
see why the Python idiom is the way it is: why should we NOT be
placing classes in their own separate files?

Thoughts, comments, and insight much appreciated,
Chris

[Jarek Zgoda]

Re: Why NOT only one class per file?

Chris Lasher napisa³(a):

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.
>
I tried to rationalize this Python idiom by claiming a file--a single
module--makes for a great container of code which is logically tied
together, such as a class and its subclasses. He posited that
directories (packages) can tie the files together just as well, and by
having the classes as separate files, he can "diff" them to see how
they differ, something he wouldn't be able to do with the code all in
one file.

I'd not try to rationalize it, it's just natural. The requirement to
have only one public class per module needs rationalization (other than
limitation of compiler), not the freedom to have as much of classes in
module as is needed by program's architecure.

--
Jarek Zgoda

http://jpa.berlios.de/

[Steve Holden]

Re: Why NOT only one class per file?

Jarek Zgoda wrote:

Chris Lasher napisa³(a):
>

>A friend of mine with a programming background in Java and Perl places
>each class in its own separate file in . I informed him that keeping
>all related classes together in a single file is more in the Python
>idiom than one file per class. He asked why, and frankly, his valid
>question has me flummoxed.
>>
>I tried to rationalize this Python idiom by claiming a file--a single
>module--makes for a great container of code which is logically tied
>together, such as a class and its subclasses. He posited that
>directories (packages) can tie the files together just as well, and by
>having the classes as separate files, he can "diff" them to see how
>they differ, something he wouldn't be able to do with the code all in
>one file.

>
I'd not try to rationalize it, it's just natural. The requirement to
have only one public class per module needs rationalization (other than
limitation of compiler), not the freedom to have as much of classes in
module as is needed by program's architecure.
>

The fact that your friend find being able to diff his classes valuable
implies that he isn't taking much advantage of modularity anyway but
instead using copy-and-paste techniques. Of course I may be doing him a
disservice.

In Java *everything* has to be in a class, unlike in Python. The module
seems a much more natural unit of storage to me, and to force us to put
each class in its own module would seem unnatural.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[=?ISO-8859-1?Q?Thomas_Kr=FCger?=]

Re: Why NOT only one class per file?

Chris Lasher schrieb:

why should we NOT be
placing classes in their own separate files?
>
Thoughts, comments, and insight much appreciated,

At first: if he really like it he can place every class in a single
file. But there are some reasons why Python "allows" you to place many
classes in one file:

- It's (a little bit) faster, no additional file system lookup is needed. ;)
- You can define a class in a class. Django, for example, uses this for
it's data models. If you do this you are forced to have multiple classes
in on file. Example:

http://www.djangoproject.com/documentation/tutorial02/#make-the-poll-app-modifiable-in-the-admin

See also:

http://mail.python.org/pipermail/python-list/2006-December/418363.html

Thomas

[Klaas]

Re: Why NOT only one class per file?

On Apr 4, 2:52 pm, Thomas Krüger <newsgro...@nos pam.nowire.orgw rote:

>
At first: if he really like it he can place every class in a single
file. But there are some reasons why Python "allows" you to place many
classes in one file:
>
- It's (a little bit) faster, no additional file system lookup is needed.;)
- You can define a class in a class. Django, for example, uses this for
it's data models. If you do this you are forced to have multiple classes
in on file. Example:http://www.djangoproject.com/documen...make-the-poll-...

That is somewhat specious: inner classes can be defined in java too.

The main reason is that in java, classes are magical entities which
correspond to one "exportable " unit of code. Thus it makes a great
deal of sense to limit to one _public_ class per file (java also
allows unlimited private and package-private classes defined in a
single file).

If you want to define a bunch of utility functions in java, you write
a file containing a single class with static methods.

In python, classes do not have special status. The exportable unit of
code is a module, which, like public classes in java, can contain
functions, static variables, and classes. Similar to java, you are
limited to a single module object per file (modulo extreme trickery).

If you want to define a bunch of utility functions in python, you
write a file containing a single module with functions.

-Mike

[Bruno Desthuilliers]

Re: Why NOT only one class per file?

Chris Lasher a écrit :

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why,

Why not ?

and frankly, his valid
question has me flummoxed.
>
I tried to rationalize this Python idiom by claiming a file--a single
module--makes for a great container of code which is logically tied
together, such as a class and its subclasses. He posited that
directories (packages) can tie the files together just as well,

With much more verbosity and boilerplate code...

and by
having the classes as separate files, he can "diff" them to see how
they differ, something he wouldn't be able to do with the code all in
one file.

Bullshit. diff used to exist way before Java. And it's still used for
languages that have no notion of 'class'. I use it on an almost daily
basis, FWIW.

I also offered that having related classes under one file gives more
direct access to those classes, e.g.:

(snip)

He doesn't find my arguments convincing,

Then he's a bit on the masochist side.

so I thought I'd ask here to
see why the Python idiom is the way it is: why should we NOT be
placing classes in their own separate files?

Because it just sucks.

Ok, let's have an example: I'm currently working on adding
ActiveRecord-like validation to Elixir, and here's one of my classes:
"""
class ValidatePresenc eOfStatement(Va lidateWithState ment):
def __init__(self, entity, column, when='on_save') :
validator = validators.not_ empty
super(ValidateW ithStatement, self).__init__( entity, column,
validator, when)

validate_presen ce_of = Statement(Valid atePresenceOfSt atement)
"""

Four (4) lines of code. Should I really consider putting this in a
separate file ? And what about my functions, then ? Should they all live
in a separate file too?

FWIW, I'm also currently working on a Plone application developped by a
(somewhat braindead) Java programmer, who of course did the
'one-class-per-file' dance. *It's a pure nightmare*. I constantly have
to switch between dozens of files to find things that are so obviously
tied together that they should belong to a single module. In some cases,
there's more import statements than effective code. Talk about a waste
of time.

Thoughts, comments, and insight much appreciated,

Just ask him why Java insists on 'one-(public)-class-per-file', and why
it's considered good form in C++. I mean, the real *technical* reasons...

[Fuzzyman]

Re: Why NOT only one class per file?

On Apr 4, 10:23 pm, "Chris Lasher" <chris.las...@g mail.comwrote:

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.
>

Only tightly coupled (and short) classes and functions.

It is better to keep modules as short as possible (and classes to),
without being ridiculous.

It is kind of obvious that keeping stub classes (exceptions for
example) in the same file is a good thing.

Diffing classes doesn't seem like a terribly good use-case: classes
that are *that* similar badly need refactoring into less classes...

Fuzzyman

http://www.voidspace.org.uk/python/articles.shtml

[Fuzzyman]

Re: Why NOT only one class per file?

On Apr 4, 11:38 pm, "Klaas" <mike.kl...@gma il.comwrote:

On Apr 4, 2:52 pm, Thomas Krüger <newsgro...@nos pam.nowire.orgw rote:
>
>
>

At first: if he really like it he can place every class in a single
file. But there are some reasons why Python "allows" you to place many
classes in one file:

>

- It's (a little bit) faster, no additional file system lookup is needed. ;)
- You can define a class in a class. Django, for example, uses this for
it's data models. If you do this you are forced to have multiple classes
in on file. Example:http://www.djangoproject.com/documen...make-the-poll-...

>
That is somewhat specious: inner classes can be defined in java too.
>
The main reason is that in java, classes are magical entities which
correspond to one "exportable " unit of code. Thus it makes a great
deal of sense to limit to one _public_ class per file (java also
allows unlimited private and package-private classes defined in a
single file).
>
If you want to define a bunch of utility functions in java, you write
a file containing a single class with static methods.
>
In python, classes do not have special status. The exportable unit of
code is a module, which, like public classes in java, can contain
functions, static variables, and classes. Similar to java, you are
limited to a single module object per file (modulo extreme trickery).
>
If you want to define a bunch of utility functions in python, you
write a file containing a single module with functions.
>

So Python has one less level of enforced nesting. :-)

Fuzzyman

http://www.voidspace.org.uk/python/articles.shtml

-Mike

[Terry Reedy]

Re: Why NOT only one class per file?


"Chris Lasher" <chris.lasher@g mail.comwrote in message
news:1175721799 .714907.52770@o 5g2000hsb.googl egroups.com...
|A friend of mine with a programming background in Java and Perl places
| each class in its own separate file in . I informed him that keeping
| all related classes together in a single file is more in the Python
| idiom than one file per class. He asked why, and frankly, his valid
| question has me flummoxed.

Ask him why he does not wear a straightjacket all the time.
It is great for one's posture ;-)

[Dillon Collins]

Re: Why NOT only one class per file?

On Wednesday 04 April 2007, Chris Lasher wrote:

He doesn't find my arguments convincing, so I thought I'd ask here to
see why the Python idiom is the way it is: why should we NOT be
placing classes in their own separate files?

Because it really just provides as an artificial limitation that could only be
annoying at best? After all, programmers can put one class per file if the
want anyway.

I know I would like Python less if I had to make a directory of files each
with somehing like:

class MyError(Excepti on):
pass

Of course, there are other cases as well where logically grouping classes is
much nicer. However, at the end of the day the question is almost
meaningless because of the way Python treats classes.
Examples:

class A(object):
class B:
pass
C=A.B

class A(object):
pass
A=1

class A(object):
pass
B=type('B', (object,), {})


The first creates a class with a contained class, but then "exports" the
contained class as C. The second creates class A, but then destroys it by
writing over it with the value 1. The third also creates a class A, but this
time creates a top-level class B. You'll note that the method of
construction allows for B to be created dynamically.

So the idea of one class per file is almost meaningless.

[Sherm Pendley]

Re: Why NOT only one class per file?

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.frwrite s:

Chris Lasher a écrit :
>

>so I thought I'd ask here to
>see why the Python idiom is the way it is: why should we NOT be
>placing classes in their own separate files?

>
Because it just sucks.

....

Just ask him why Java insists on 'one-(public)-class-per-file', and
why it's considered good form in C++. I mean, the real *technical*
reasons...

Yeah, as if "because it just sucks" is a technical reason. :-)

It's a stylistic thing, nothing more. There's no technical basis for it,
just personal preference.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Steven Howe]

Re: Why NOT only one class per file?

Dennis Lee Bieber wrote:

On 4 Apr 2007 14:23:19 -0700, "Chris Lasher" <chris.lasher@g mail.com>
declaimed the following in comp.lang.pytho n:
>
>

>A friend of mine with a programming background in Java and Perl places
>each class in its own separate file in . I informed him that keeping
>all related classes together in a single file is more in the Python
>idiom than one file per class. He asked why, and frankly, his valid
>question has me flummoxed.
>>
>>

As I recall, Java essentially doesn't offer a CHOICE... So I'd
consider any argument that "one per file" is best to be flawed if based
upon Java practice. After all, if one can not even experiment with other
ways, how can one really evaluate the options? {and I consign Perl to
realms described by Dante}
>

On class per file was easier to do when Java was developed (remember it
was develop to control
vending machines; scary. Reminds me of the movie 'Tron'). The desktop
computer for Sun
was an IPC workstation. Nice but no balls and no good editors that
could have 24+ tabs open or
a way to 'close' sections of coherent text (which are common in my
preferred editor, Komodo).

So your friend is arguing the past. Ask him if he's a Republican too or
needs a serious reboot.
I have a good pair of boot to give him a kick in the ass (Democrats
would need a kick in the head
to reset; we all know what organ Republican think with).
sph

[Hendrik van Rooyen]

Re: Why NOT only one class per file?

"Terry Reedy" <tjreedy@udel.e duwrote:

Ask him why he does not wear a straightjacket all the time.
It is great for one's posture ;-)

No it isn't - those funny arms give you round shoulders..

- Hendrik

[Bruno Desthuilliers]

Re: Why NOT only one class per file?

Sherm Pendley a écrit :

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.frwrite s:
>

>Chris Lasher a écrit :
>>

>>so I thought I'd ask here to
>>see why the Python idiom is the way it is: why should we NOT be
>>placing classes in their own separate files?

>Because it just sucks.

>
...
>

>Just ask him why Java insists on 'one-(public)-class-per-file', and
>why it's considered good form in C++. I mean, the real *technical*
>reasons...

>
Yeah, as if "because it just sucks" is a technical reason. :-)

It doesn't pretend to be one !-)

It's a stylistic thing, nothing more.

A bit more than just 'stylistic' IMHO. It's a matter of convenience.
Having to manage hundreds of files each with a dozen lines of code is a
PITA. Having to retype the same import statements in hundreds of files
is a PITA - and a good way to waste time and forget something when one
has to fix these import statements (yes, even with the appropriate
tediting tools). I wouldn't call such considerations "nothing more than
stylistic".

There's no technical basis for it,

No, but there's no technical reason for putting each class in a separate
file.

just personal preference.

True, I prefer to avoid boilerplate proliferation, switching-file-dance,
and maintenance nightmares.

[Christophe]

Re: Why NOT only one class per file?

Chris Lasher a écrit :

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.

In Java, you HAVE to place a class in it's own file. That's how the
language works. But in Java, you do not have to place each class in it's
own module/package, in fact, it would be bad.

It's the same in Python: you do not want to have one class per
module/package.

Unfortunately, in Python, a module/package is a file, and in Java, it's
a directory. Also, Python doesn't really have the notion of a "root
package/module".




Translation: "import foo; foo.foo()" sucks so avoid having only one
class per module :)