One module per class, bad idea?

Discussion in 'Python' started by Matias Jansson, Dec 12, 2006.

  1. 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)?
     
    Matias Jansson, Dec 12, 2006
    #1
    1. Advertising

  2. Matias Jansson

    billie Guest

    > 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. =)
     
    billie, Dec 12, 2006
    #2
    1. Advertising

  3. 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>
     
    Fredrik Lundh, Dec 12, 2006
    #3
  4. Matias Jansson

    Fuzzyman Guest

    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
     
    Fuzzyman, Dec 12, 2006
    #4
  5. Matias Jansson

    Andy Dingley Guest

    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.
     
    Andy Dingley, Dec 12, 2006
    #5
  6. Matias Jansson

    Paddy Guest

    On Dec 12, 8:29 am, "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)?

    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.
     
    Paddy, Dec 12, 2006
    #6

  7. > 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, Dec 12, 2006
    #7

  8. > 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.
     
    Isaac Rodriguez, Dec 12, 2006
    #8
  9. 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

    Build and Release
    MontaVista Software
     
    Carl J. Van Arsdall, Dec 12, 2006
    #9
  10. On 12 dic, 16:17, "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.


    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
     
    Gabriel Genellina, Dec 12, 2006
    #10
  11. Matias Jansson

    Carl Banks Guest

    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, Dec 12, 2006
    #11
  12. Matias Jansson

    Carl Banks Guest

    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 Banks, Dec 12, 2006
    #12
  13. 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

    Build and Release
    MontaVista Software
     
    Carl J. Van Arsdall, Dec 12, 2006
    #13
  14. Matias Jansson

    Carl Banks Guest

    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
     
    Carl Banks, Dec 13, 2006
    #14
  15. Matias Jansson

    Paddy Guest

    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.
     
    Paddy, Dec 13, 2006
    #15
  16. Matias Jansson

    billie Guest

    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.
     
    billie, Dec 13, 2006
    #16
  17. Matias Jansson

    mystilleef Guest

    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.
     
    mystilleef, Dec 13, 2006
    #17
  18. Matias Jansson

    Jorgen Grahn Guest

    On Tue, 12 Dec 2006 09:29:17 +0100, 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)?


    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!
     
    Jorgen Grahn, Dec 15, 2006
    #18
  19. Matias Jansson

    Kent Johnson Guest

    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
     
    Kent Johnson, Dec 22, 2006
    #19
  20. Matias Jansson

    Carl Banks Guest

    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, Dec 22, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?S01aX3N0YXRl?=

    Quick one - Is SESSION per browser instance or per IP Address?

    =?Utf-8?B?S01aX3N0YXRl?=, Apr 4, 2006, in forum: ASP .Net
    Replies:
    7
    Views:
    5,944
    gerry
    Apr 10, 2006
  2. Replies:
    5
    Views:
    2,631
  3. Replies:
    0
    Views:
    369
  4. Replies:
    10
    Views:
    1,269
    Big K
    Feb 2, 2005
  5. rantingrick
    Replies:
    44
    Views:
    1,297
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page