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]

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]

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 [phone] [phone]
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?=]

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/documen...e-in-the-admin

See also:
http://mail.python.org/pipermail/pyt...er/418363.html

Thomas

[Klaas]

On Apr 4, 2:52 pm, Thomas Krüger <[e-mail]:

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

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 ValidatePresenceOfStatement(ValidateWithStatement) :
def __init__(self, entity, column, when='on_save'):
validator = validators.not_empty
super(ValidateWithStatement, self).__init__(entity, column,
validator, when)

validate_presence_of = Statement(ValidatePresenceOfStatement)
"""

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]

On Apr 4, 10:23 pm, "Chris Lasher" <[e-mail]:

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]

On Apr 4, 11:38 pm, "Klaas" <[e-mail]:

On Apr 4, 2:52 pm, Thomas Krüger <[e-mail]:

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]

"Chris Lasher" <ch**********@gmail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.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]

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(Exception):
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]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

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]

Dennis Lee Bieber wrote:

On 4 Apr 2007 14:23:19 -0700, "Chris Lasher" <ch**********@gmail.com>
declaimed the following in comp.lang.python:

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

"Terry Reedy" <tj*****@udel.eduwrote:

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]

Sherm Pendley a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

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

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

[Sherm Pendley]

Steven Howe <ho*********@gmail.comwrites:

On class per file was easier to do when Java was developed (remember
it was develop to control vending machines

Not quite. Java grew out of a set-top box at Sun, code-named "Oak".

>; scary. Reminds me of the movie 'Tron'

Vending machines in "Tron" were pussycats compared to the one in "Maximum
Overdrive." :-)

sherm--

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

[Steve Holden]

Christophe wrote:

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

One further thought:

http://www.artima.com/weblogs/viewpost.jsp?thread=42242

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[Sherm Pendley]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ites:

Sherm Pendley a écrit :

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

Yes, but the pain in that case comes from having hundreds of trivial
classes, not from the way in which the source for them is organized.

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

Neither would I. But then, I would describe the existence of all those
files as just the symptom - the real problem being the design that needs
all of those hundreds of trivial classes in the first place.

Granted, I know very little of Python. It may be the case that Python
encourages the use of hundreds of "little classes" - and if that is the
case, then I agree, storing each one in its own file would be rather
absurd.

I'm more accustomed to writing classes that tend to be larger - hundreds
if not thousands of lines each, or more - and in that case, storing them
one per file is a reasonable way to organize one's sources.

sherm--

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

[Nate Finch]

So, here's a view from a guy who's not a python nut and has a long
history of professional programming in other languages (C++, C, C#,
Java)

I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either. You
talk about the "changing file dance", but what about the "scroll for
30 seconds" dance? What about the "six different conflicts in source
control because everything's in one file" dance?

I think it doesn't matter how many classes and/or functions you have
in one file as long as you keep files to a reasonable size. If you've
ever worked on a medium to large-scale project using multiple
developers and tens or hundreds of thousands of lines of code, then
you know that keeping code separate in source control is highly
important. If I'm working on extending one class and someone else is
working on another class... it's much less of a headache if they're in
separate files in source control. Then you don't have to worry about
conflicts and merging. I think that's the number one benefit for
short files (not necessarily just one class per file).

My cutoff is around 500 lines per file. If a file goes much over
that, it's really time to start looking for a way to break it up.

Sure, if all your classes are 4 lines long, then by all means, stick
them all in one file. But I don't think that's really any kind of
valid stance to argue from. Sure, if you don't need organization, it
doesn't matter what organization technique you use. But if you do
need organization, it does matter. And I think one class per file is
an acceptable way to go about it, especially when your classes tend to
be over a couple hundred lines long.

-Nate

[Bruno Desthuilliers]

Nate Finch a écrit :

So, here's a view from a guy who's not a python nut and has a long
history of professional programming in other languages (C++, C, C#,
Java)

I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

Nope. What matters is to have
- logical grouping of code units (high cohesion)
- manageable files (not too much files, not too large files - of course
the balance depends on the project as well).

There are quite a few professional programmers here with experience on
medium to large to huge projects with different languages, you know.

[John Nagle]

Nate Finch wrote:

I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

John Nagle

[Paddy]

On Apr 5, 5:51 pm, John Nagle <[e-mail]:

Nate Finch wrote:

I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

John Nagle

Some languages (Specman e, and I think Perl), have the concept of
begin and end end markers. The interpreted/compiled code is what is
seen between those markers allowing the source to be embedded in
other
text.

[Bruno Desthuilliers]

Sherm Pendley a écrit :

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ites:

>>Sherm Pendley a écrit :

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

Yes, but the pain in that case comes from having hundreds of trivial
classes,

The fact that a class is short doesn't imply it's trivial.

not from the way in which the source for them is organized.

I have to disagree. Having several, closely related objects (ie:
classes, functions, etc) in a same file allow to "see the big picture",
and avoids the mental overhead of navigating thru files, directories,
opened windows etc.

Of course, it doesn't mean that one should store the whole program in a
single monster file - I usually start to rearrange things when the file
grows bigger than one thousand lines.

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

Neither would I. But then, I would describe the existence of all those
files as just the symptom - the real problem being the design that needs
all of those hundreds of trivial classes in the first place.

In my book, it's huge classes and methods that are usually a smell of a
design problem. Specially with languages like Python or Ruby. Factoring
out code duplication usually leads to lot of small objects - and also to
a significant reduction of the code base's size.

Granted, I know very little of Python. It may be the case that Python
encourages the use of hundreds of "little classes"

Python being very expressive, and having powerful metaprogramming
features, there's usually much less boilerplate (than in languages like
Java) for a same result. So yes, it's quite usual to have small classes
and functions.

- and if that is the
case, then I agree, storing each one in its own file would be rather
absurd.

Indeed. That's the point (or at least part of it).

I'm more accustomed to writing classes that tend to be larger - hundreds
if not thousands of lines each,

It sometimes happens that a class or function needs to be much bigger
than the average. So be it. But if I found myself writing
thousands-lines classes in Python, I'd start to seriously consider
rethinking the whole stuff.... Heck, I have very few *modules* that are
more than one thousand lines long, and almost never a single class per
module.

or more -

In Python ???

[Bruno Desthuilliers]

John Nagle a écrit :

Nate Finch wrote:

>I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Having source code as text files may not be such a bad thing. Diffing,
grepping and versioning binary files is not that easy...

Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in separate
files, and the 'rendering' code (views, templates, call them what you
like) are seldom full html documents.

[Nate Finch]

On Apr 5, 10:48 am, Bruno Desthuilliers <bruno.
[e-mail]:

Nate Finch a écrit :

So, here's a view from a guy who's not a python nut and has a long
history of professional programming in other languages (C++, C, C#,
Java)

There are quite a few professional programmers here with experience on
medium to large to huge projects with different languages, you know.

Sorry, I meant to go back and edit that phrase to sound less
condescending. I know there are a lot of professional programmers on
here, and I didn't mean to imply otherwise. It wasn't supposed to be
a contrast to everyone, just introducing myself.

I totally agree with you... there's a balance between too many files
and files that are too large.

As to the guy who writes 1000+ line classes .... dude, refactor some.
You're trying to make the class do too much, almost by definition.

We have *some* classes that big, and they're marked as "needs
refactor". It's certainly not a common occurance, though. Usually
they're UI classes, since they require a lot of verbose positioning of
elements and hooking of events.
And while people are reading this thread, let me plug my other thread,
asking about absolute_import. I'd really love some help :)

-Nate

[Steve Holden]

Bruno Desthuilliers wrote:

John Nagle a écrit :

>Nate Finch wrote:

[...]

>

> Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in separate
files, and the 'rendering' code (views, templates, call them what you
like) are seldom full html documents.

And it's perfectly possible to write a PHP program that isn't a web
page. It's just that PHP is such an awful language nobody chooses to do it.

Perhaps I'm not being fair to PHP. It's just been pushed so far beyond
its original design limits that it's screamingly uncomfortable to use.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[Sherm Pendley]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

Sherm Pendley a écrit :

In my book, it's huge classes and methods that are usually a smell of
a design problem.

Obviously we're reading different books.

But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

sherm--

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

[Sherm Pendley]

"Nate Finch" <na********@gmail.comwrites:

As to the guy who writes 1000+ line classes .... dude, refactor some.
You're trying to make the class do too much, almost by definition.

You haven't even seen my code, you don't even know what language it's in,
but you're telling me it's wrong?

Wow - and I thought *I* was arrogant.

sherm--

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

[Bruno Desthuilliers]

Steve Holden a écrit :

Bruno Desthuilliers wrote:

>John Nagle a écrit :

>>Nate Finch wrote:

[...]

>>

>> Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in
separate files, and the 'rendering' code (views, templates, call them
what you like) are seldom full html documents.

And it's perfectly possible to write a PHP program that isn't a web
page. It's just that PHP is such an awful language nobody chooses to do it.

Perhaps I'm not being fair to PHP. It's just been pushed so far beyond
its original design limits that it's screamingly uncomfortable to use.

original design ? Which original design ?-)

[Bruno Desthuilliers]

Sherm Pendley a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

>>Sherm Pendley a écrit :

In my book, it's huge classes and methods that are usually a smell of
a design problem.

Obviously we're reading different books.

Obviously. But I didn't gain this knowledge from books.

FWIW, I'd be interested if you'd let us know about any book pretending
that monster classes are good design !-)

But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

It seems that it works well for almost anyone having some real-world
experience with languages like Python. Experience with C++, Java,
ObjectPascal, (insert your favorite verbose low-level language here) may
not apply here.

[Carl Banks]

On Apr 4, 5:23 pm, "Chris Lasher" <[e-mail]:

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.

A: Because you don't have to.

Less smart aleck: Python allows programmers to put more than one class
per file. Given that freedom, most people didn't obey one-to-one
correspondence between classes and files. Therefore, it's the more
common idiom in Python.

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,

Which is not incorrect.

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 agree with Bruno: feeling the need to do this is a big red flag that
the code is way too cut-and-paste.

(diff'ing different versions is useful, of course, but you can
usefully diff modules with many classes in them.)

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

[snip examples]

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?

There's no overwhelming reason not to, IMO. As long you have some
organization, be it with packages or modules, everything's ok. Most
things you have to gain or lose by doing one way or the other are of
minor importance.
Carl Banks

[Malcolm Dew-Jones]

Chris Lasher (ch**********@gmail.com) wrote:
: A friend of mine with a programming background in Java and Perl places
: each class in its own separate file in .

Java doesn't actually require one class per file, it requires one public
class per file. You can have any number of helper classes in the same
file.

Perl doesn't require anything, and files and classes are almost entirely
different things (except by useful convention).

I'm only just getting into python, so I have no opinions yet.

[John Nagle]

Bruno Desthuilliers wrote:

John Nagle a écrit :

>Nate Finch wrote:

Having source code as text files may not be such a bad thing. Diffing,
grepping and versioning binary files is not that easy...

There are tools for that sort of thing, although they're not well
known in the open source world. Check out "http://www.alienbrain.com"
and view the demo. Alienbrain is used for configuration management on
major game development projects, where there are dozens of different
types of "assets", from code to motion capture data to images to audio
to video to 3D geometry. All the stuff programmers expect, like build
management, version control, history, and differencing, are all there.
But they're not limited to text files.

I'm not suggesting this for Python, but it's interesting to consider
that perhaps web development needs tools more like this.

John Nagle

[Sherm Pendley]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

Sherm Pendley a écrit :

>Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

>>>Sherm Pendley a écrit :

In my book, it's huge classes and methods that are usually a smell of
a design problem.

Obviously we're reading different books.

Obviously. But I didn't gain this knowledge from books.

Obviously, you have no sense of humor.

FWIW, I'd be interested if you'd let us know about any book pretending
that monster classes are good design !-)

You've already decided that "monster classes" are bad design, and that
anything conflicting with your belief is mere pretense. Why should I waste
my time debating when you've already made up your mind?

>But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

It seems that it works well for almost anyone having some real-world
experience with languages like Python.

I didn't say otherwise. You're arguing a false dichotomy; the fact that one
approach works well does not prove that others won't work equally well. I'm
not saying that your preferred style is wrong; I'm just saying that it's a
matter of preference, not a universal truth.

sherm--

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

[Alex Martelli]

John Nagle <na***@animats.comwrote:

systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

APL was that way, too. And now the ACM wants to dissolve the APL SIG --
there just isn't anything much happening there any more:-(
Alex

[Paul Rubin]

John Nagle <na***@animats.comwrites:

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

See also "literate programming", including the version built into Haskell.

[Steven D'Aprano]

On Wed, 04 Apr 2007 14:23:19 -0700, Chris Lasher wrote:

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.

Hah! Writing one class per file is for wimps! When I program, I write one
*method* per file, then import them and build the class at runtime.

I have a friend who writes one *line* per file, then pulls them all
together with exec(), but that's just being stupid.

--
Steven.

[Bart Willems]

Steven D'Aprano wrote:

On Wed, 04 Apr 2007 14:23:19 -0700, Chris Lasher wrote:

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

Hah! Writing one class per file is for wimps! When I program, I write one
*method* per file, then import them and build the class at runtime.

I have a friend who writes one *line* per file, then pulls them all
together with exec(), but that's just being stupid.

I guess you're one of those sissies who uses EDLIN as an editor.

REAL programmers use COPY CON: ... :)

[Greg Donald]

On 4/6/07, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:

For one liners, wouldn't

ECHO the text line >the.file

be more appropriate? <G>

# dd if=/dev/tty of=/dev/hda1

--
Greg Donald
http://destiney.com/

[Hendrik van Rooyen]

"Bart Willems" <b.*********@gmail.comwrote:

Steven D'Aprano wrote:

On Wed, 04 Apr 2007 14:23:19 -0700, Chris Lasher wrote:

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.

Hah! Writing one class per file is for wimps! When I program, I write one
*method* per file, then import them and build the class at runtime.

I have a friend who writes one *line* per file, then pulls them all
together with exec(), but that's just being stupid.

I guess you're one of those sissies who uses EDLIN as an editor.

REAL programmers use COPY CON: ... :)

Naaah.. Real programmers fill in their coding sheets using
indelible ink in their fountain pens, and then send them off
to be punched and verified.

None of this weak minded backspace stuff for us...

- Hendrik

[Chris Lasher]

On Apr 4, 5:23 pm, "Chris Lasher" <[e-mail]:

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.

[snip]

Thoughts, comments, and insight much appreciated,
Chris

Thanks to all who replied and made this a very interesting and
informative discussion! It gave my friend, and myself, plenty to think
about.

Much appreciated,
Chris

[Bruno Desthuilliers]

Sherm Pendley a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

>>Sherm Pendley a écrit :

>>>Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

Sherm Pendley a écrit :

In my book, it's huge classes and methods that are usually a smell of
a design problem.
Obviously we're reading different books.

Obviously. But I didn't gain this knowledge from books.

Obviously, you have no sense of humor.

Obviously, we don't have the same sense of humor.

>>FWIW, I'd be interested if you'd let us know about any book pretending
that monster classes are good design !-)

You've already decided that "monster classes" are bad design,

I came to this conclusion from my own experience, and it seems that
quite a few other programmers (most of them either better and/or more
experimented than me) came to the same conclusion. But feel free to
believe it's an a priori if that makes you feel better.

and that
anything conflicting with your belief is mere pretense. Why should I waste
my time debating when you've already made up your mind?

Then don't. But I'd still be interested if you could let us know about
any book advocating monster classes as good design.

>>>But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

It seems that it works well for almost anyone having some real-world
experience with languages like Python.

I didn't say otherwise.

So let's rephrase your previous assertion :
"what works well for almost anyone having some real world experience
with languages like Python isn't necessarily what works well for
everyone" (implied : "... when using a Python-like language" - this
seemed obvious but it may be better to state it more explicitly, just in
case...).

You're arguing a false dichotomy;

Nope, just stating a fact - from which you may or not derive some
conclusions.

the fact that one
approach works well does not prove that others won't work equally well.

The fact that a in a given context a significant majority of
experimented users usually favors one approach over the other might be
taken as an indication that there might be some reason for this.

About "proofs", I'm afraid that "proving" things learned from experience
can be sometimes difficult - or at least above my own skills, specially
in a language I'm not very fluent with. But I think I did tried (perhaps
unsuccessfully, but that's another problem) to back my POV, instead of
just resorting to rethoric like you're doing here.

I'm
not saying that your preferred style is wrong; I'm just saying that it's a
matter of preference, not a universal truth.

If it was only *my* "preferred style", I wouldn't even argue. Now I'm
not presenting it as a "universal truth", but as the result of
experience (and not only my own) with a given class of languages.

Asserting that one should *always* only put one class per file is just
as non-sensical as asserting that one should *always* put several
classes in a same file. Not only because Python doesn't requires you to
use classes, but mostly because it's arbitrary and dogmatic. You seem to
have (dis)missed the point where I said that I *almost* never had a
single class in a file - which implies that I *sometimes* do this - when
it makes sens from either a practical or logical POV.

FWIW, I would certainly not try to apply this "preferred style" when
writing GUIs in C++. You see, the fact that some idiom (style, whatever)
works well with a given (class of) language(s) doesn't mean it's the
more effective in some other context. Here again, it seems that you
(dis)missed the point where I asked you if your thousands-lines-long
classes were written in Python.