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"
<[e-mail]:

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

[Gabriel Genellina]

On 12 dic, 16:17, "Isaac Rodriguez" <[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

[Carl Banks]

Carl J. Van Arsdall wrote:

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

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

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]

Carl Banks wrote:

Carl J. Van Arsdall wrote:

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

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

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

[Carl Banks]

Carl J. Van Arsdall wrote:

Carl Banks wrote:

Carl J. Van Arsdall wrote:

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

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]

Isaac Rodriguez wrote:

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]

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.

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]

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

On Tue, 12 Dec 2006 09:29:17 +0100, Matias Jansson <ma************@carmenconsulting.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)?

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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

[Kent Johnson]

Carl Banks wrote:

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]

Kent Johnson wrote:

Carl Banks wrote:

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.

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

[Erik Johnson]

There are arguments of preference to be made on both sides. I think the
question largely comes down to what is "workable" and "maintainable". To
answer the original question, I think it is not necessarily a bad idea to
have one class per file. But if your classes are small, or certain classes
are logically related to other classes (e.g., one class is a subclass of
another, or one class is implemented in terms of another, or the two classes
work together to accomplish some task and it wouldn't make much sense to be
using just one of the classes), it makes a lot of sense to keep them
together in the same file. If your classes are only a few dozen lines,
making lots of files may be more of a pain than having the code together in
one file.

Where I work, we started with a set of classes that provided a layer of
abstraction and encapsulation to accessing our database tables. An object
was basically just a loaded DB record and generally didn't provide a lot
else. As time went on, we started to code more and more logic into these
classes that provided various functions to make it easy to load records, do
certain kinds of computations and filtering with them, to generate the SQL
to do the insert for the record, etc.

The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history). Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up. So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off. In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

So... there's no magic "one size fits all" answer here - do what makes
sense.

As Carl points out, decent editors should be able to handle dispaying
different files. I use vim and know I can split the window (both
horizontally and vertically), editing either different sections of the same
file or different files and can cut and paste between the two windows. In
practice, I usually just jump between places in the same file under a single
window, or I textually cut and paste between two separate vim sessions, but
if that's something you need to do a lot, you might want to invest a bit in
learning how to use split windows in your editor. Some of the documentation
for doing this under vim can be found here:
http://vimdoc.sourceforge.net/htmldo...ws.html#:split and here:
http://vimdoc.sourceforge.net/htmldoc/usr_08.html
(I'm sure emacs can do this as well, but I don't know emacs.) If your
editor can't handle similar tasks, you might want to consider getting a
better editor.

HTH,
-ej
"Carl Banks" <pa************@gmail.comwrote in message
news:11**********************@42g2000cwt.googlegro ups.com...

Kent Johnson wrote:

Carl Banks wrote:

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.

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

[Carl Banks]

Erik Johnson wrote:

The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history). Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up. So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off. In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

Refactor NOW. I realize this is not as easy to do for a large team
than it is for a solo programmer like me, but ISTM people tend to
overestimate the cost and underestimate the benefit of it. And I've
seen some pretty bad excuses besides for not doing it. (But how can we
refactor when we have programmers checking stuff out all the time? Um,
how bout doing it during off hours? But it's too much to do in a
weekend! Which only goes to show you you've let it go too far.
Refactor in small doses.)

I have two files ~1000 lines that are marked as "these files are
getting too big". (They currently define 20 and 24 classes--though in
fairness the one with 24 has a bunch of small mixins.) Soon as this
overloaded holiday season is over, they're getting broken up.

So... there's no magic "one size fits all" answer here - do what makes
sense.

As Carl points out, decent editors should be able to handle dispaying
different files.

Actually, I pointed out that decent editors should be able to handle
displaying the same file twice. In case you want to edit two different
points of the same file side-by-side.
Carl Banks

[Paddy]

Carl Banks wrote:

Erik Johnson wrote:

The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history). Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up. So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off. In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

Refactor NOW.
Carl Banks

Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?

[Gabriel Genellina]

At Friday 22/12/2006 12:56, Kent Johnson wrote:

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

You can always arrange things at the module level (inside
__init__.py) so from "outside", people can say:
from foo.bar import MyClass
if you consider MyClass being in its own module an implementation
detail that should be hidden.
<opinion class=personal>Module layout is an important design concept</opinion>
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Gabriel Genellina]

At Friday 22/12/2006 20:25, Paddy wrote:

>Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?

Usually no other files need to change. Ex: you have BigOldModule
including ClassA, ClassB and FunctionC. Move each one onto its own
module, perhaps including a subset of the original imports of BigOldModule.
Shrink BigOldModule to just:

from ClassA import ClassA
from ClassB import ClassB
from functionC import functionC

and maybe a few other things, so all imports from the outside remain
the same. That's all - most of the time.
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Carl Banks]

Paddy wrote:

Carl Banks wrote:

Erik Johnson wrote:

The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history). Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up. So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off. In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

Refactor NOW.

Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?

I don't know what spiffy tools there are. If all I'm doing is moving a
class from one module to another, then a simple interactive search and
replace suffices for me; I modify import lines by hand.
Carl Banks

[Carl Banks]

Gabriel Genellina wrote:

At Friday 22/12/2006 20:25, Paddy wrote:

Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?

Usually no other files need to change. Ex: you have BigOldModule
including ClassA, ClassB and FunctionC. Move each one onto its own
module, perhaps including a subset of the original imports of BigOldModule.
Shrink BigOldModule to just:

from ClassA import ClassA
from ClassB import ClassB
from functionC import functionC

and maybe a few other things, so all imports from the outside remain
the same. That's all - most of the time.

I wouldn't recommend this unless it's important not to change the
external usage. If you're doing it just to save work in refactoring,
it's a partial solution hack that'll lead to more confusion and delay a
real solution even more.
Carl Banks

[Ben Finney]

"Paddy" <pa*******@netscape.netwrites:

Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?

Sounds like a good feature to add to Bicycle Repair Man:

<URL:http://bicyclerepair.sourceforge.net/>

--
\ Q: "I've heard that Linux causes cancer..." Torvalds: "That's |
`\ a filthy lie. Besides, it was only in rats and has not been |
_o__) reproduced in humans." -- Linus Torvalds |
Ben Finney

[Gabriel Genellina]

At Friday 22/12/2006 22:58, Carl Banks wrote:

Usually no other files need to change. Ex: you have BigOldModule
including ClassA, ClassB and FunctionC. Move each one onto its own
module, perhaps including a subset of the original imports of BigOldModule.
Shrink BigOldModule to just:

from ClassA import ClassA
from ClassB import ClassB
from functionC import functionC

and maybe a few other things, so all imports from the outside remain
the same. That's all - most of the time.

I wouldn't recommend this unless it's important not to change the
external usage. If you're doing it just to save work in refactoring,
it's a partial solution hack that'll lead to more confusion and delay a
real solution even more.

In some cases you may consider the fact that ClassA is contained in
its own module, just an implementation detail, and not part of the
package public interfase.
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Carl Banks]

Gabriel Genellina wrote:

At Friday 22/12/2006 22:58, Carl Banks wrote:

Usually no other files need to change. Ex: you have BigOldModule
including ClassA, ClassB and FunctionC. Move each one onto its own
module, perhaps including a subset of the original imports of BigOldModule.
Shrink BigOldModule to just:
>
from ClassA import ClassA
from ClassB import ClassB
from functionC import functionC
>
and maybe a few other things, so all imports from the outside remain
the same. That's all - most of the time.

I wouldn't recommend this unless it's important not to change the
external usage. If you're doing it just to save work in refactoring,
it's a partial solution hack that'll lead to more confusion and delay a
real solution even more.

In some cases you may consider the fact that ClassA is contained in
its own module, just an implementation detail, and not part of the
package public interfase.

Yes, I would say that falls under the "important not to change the
external usage" exception I gave.

Carl Banks

[stdazi]

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

IMO, even the Java practice is weird. I think classes should be split
into different files/modules due to their context and not their
number...

[Kent Johnson]

Carl Banks wrote:

Kent Johnson wrote:

>Carl Banks wrote:

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

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.

But then to go back to where you were, you have to scroll back and find
your place. For me, just a click or keystroke to restore the last file
with the cursor or selection exactly where I left it. And if I am going
back and forth between the two, each switch is equally easy after the
first (opening the file).

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

Right, at a cost of showing you half as much of the one you care about.

Anyway, I'm not trying to convince anyone to change, just pointing out
that there are different styles of editing that make sense to those who
use them, if not to outside observers ;-)

Kent

[Carl Banks]

Kent Johnson wrote:

Carl Banks wrote:

Kent Johnson wrote:

Carl Banks wrote:
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.

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.

But then to go back to where you were, you have to scroll back and find
your place.

See, I find that to be a lot less of a mental disruption than recalling
a filename on the spot.

For me, just a click or keystroke to restore the last file
with the cursor or selection exactly where I left it. And if I am going
back and forth between the two, each switch is equally easy after the
first (opening the file).

Ok, but doesn't your editor have bookmarks? (I don't use them, because
remembering a bookmark name is the same mental disruption for me as
remembering a filename. Sometimes I use an interactive search will get
me to where I want to go if it's more than a screen or two.)

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

Right, at a cost of showing you half as much of the one you care about.

I presume if you're looking at two different files side-by-side it's at
the same cost?

Anyway, I'm not trying to convince anyone to change, just pointing out
that there are different styles of editing that make sense to those who
use them, if not to outside observers ;-)

That's fine; I'm not knocking anyone's style. But maybe you should
just leave it at, "I just prefer small files", and cease with the
editor-based arguments.

To be sure, there are probably editors out there that can load several
files into the same buffer, which would mean I could avoid recalling
filenames even when editing multiple files. (In fact, I think I'll
look for such a solution the next time I find myself editing Java.)
It's really not about the editor; I just think that the module is the
best place for higher-level organization.

But the package will do.
Carl Banks