Re: About one class/function per module

Discussion in 'Python' started by Bruno Desthuilliers, Nov 2, 2009.

  1. Peng Yu a écrit :
    (snip)
    > I prefer organized my code one class/function per file (i.e per module
    > in python). I know the majority of programmers don't use this
    > approach. Therefore, I'm wondering what its disadvantage is.


    Hmmm... As far as I'm concerned, you already answered your own question:
    "the majority of programmers don't use this approach".

    Now, for a much more practical answer:
    1/ having to handle thousands of files for even a simple project is a
    king-size PITA for the maintainer.
    2/ having to load thousands of modules will add quite a lot of overhead
    when actually running the code.
    3/ as a result, the poor guy that will end up maintaining your code will
    positively hate you. Beware : this poor guy might as well be you.
     
    Bruno Desthuilliers, Nov 2, 2009
    #1
    1. Advertising

  2. Bruno Desthuilliers

    Peng Yu Guest

    On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
    <> wrote:
    > Peng Yu a écrit :
    > (snip)
    >>
    >> I prefer organized my code one class/function per file (i.e per module
    >> in python). I know the majority of programmers don't use this
    >> approach. Therefore, I'm wondering what its disadvantage is.

    >
    > Hmmm... As far as I'm concerned, you already answered your own question:
    > "the majority of programmers don't use this approach".
    >
    > Now, for a much more practical answer:
    > 1/ having to handle thousands of files for even a simple project is a
    > king-size PITA for the maintainer.
    > 2/ having to load thousands of modules will add quite a lot of overhead when
    > actually running the code.
    > 3/ as a result, the poor guy that will end up maintaining your code will
    > positively hate you. Beware : this poor guy might as well be you.


    I still don't understand why it is a nightmare to maintain the code.
    For my C++ project, so far so good.

    I can easily change filenames (that is class name or function name), I
    can easily find them, I can easily move things around, all with just
    the corresponding script command. I can navigate to the definition of
    class and function by vim + ctags, I can see example code that calls
    the class/function. Whenever I suspect there is a bug, I can easily go
    to the right level of class/function in the directory hierarchy to
    write a test case to trace down the bug without having to use gdb.

    Would you please let me why it is a nightmare?
     
    Peng Yu, Nov 2, 2009
    #2
    1. Advertising

  3. Bruno Desthuilliers

    Peng Yu Guest

    On Mon, Nov 2, 2009 at 7:11 AM, Peng Yu <> wrote:
    > On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
    > <> wrote:
    >> Peng Yu a écrit :
    >> (snip)
    >>>
    >>> I prefer organized my code one class/function per file (i.e per module
    >>> in python). I know the majority of programmers don't use this
    >>> approach. Therefore, I'm wondering what its disadvantage is.

    >>
    >> Hmmm... As far as I'm concerned, you already answered your own question:
    >> "the majority of programmers don't use this approach".
    >>
    >> Now, for a much more practical answer:
    >> 1/ having to handle thousands of files for even a simple project is a
    >> king-size PITA for the maintainer.
    >> 2/ having to load thousands of modules will add quite a lot of overhead when
    >> actually running the code.
    >> 3/ as a result, the poor guy that will end up maintaining your code will
    >> positively hate you. Beware : this poor guy might as well be you.

    >
    > I still don't understand why it is a nightmare to maintain the code.
    > For my C++ project, so far so good.
    >
    > I can easily change filenames (that is class name or function name), I
    > can easily find them, I can easily move things around, all with just
    > the corresponding script command. I can navigate to the definition of
    > class and function by vim + ctags, I can see example code that calls
    > the class/function. Whenever I suspect there is a bug, I can easily go
    > to the right level of class/function in the directory hierarchy to
    > write a test case to trace down the bug without having to use gdb.
    >
    > Would you please let me why it is a nightmare?


    Another advantage one of class/function per file is that the syntax
    clearly tell the dependence relation between classes and functions.

    Suppose I have class A and class B in a file, I can not easily figure
    out which class depends on which class by a simple script. However, if
    they are in two separate files, for example B depends on A, then I
    will have 'import A' in file B. This dependency can be easily figured
    out by a script.

    The following scenario also demonstrate why the maintenance cost is
    lower with one class/function per file, because it decouples
    dependences. Let's suppose class A and B are in the same file. Now I'm
    changing class B. But while I'm changing class B, I just realize that
    I have to change A. But since the change in B is half way done
    (syntactical not correct), I will not be able to run the test case for
    A, because the test case import the file that has class B. In
    contrast, if A and B are in different files, even if B is half way
    done, I can still run test case for A.
     
    Peng Yu, Nov 2, 2009
    #3
  4. Peng Yu wrote:

    > On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
    > <> wrote:
    >> Peng Yu a écrit :
    >> (snip)
    >>>
    >>> I prefer organized my code one class/function per file (i.e per module
    >>> in python). I know the majority of programmers don't use this
    >>> approach. Therefore, I'm wondering what its disadvantage is.

    >>
    >> Hmmm... As far as I'm concerned, you already answered your own question:
    >> "the majority of programmers don't use this approach".
    >>
    >> Now, for a much more practical answer:
    >> 1/ having to handle thousands of files for even a simple project is a
    >> king-size PITA for the maintainer.
    >> 2/ having to load thousands of modules will add quite a lot of overhead
    >> when actually running the code.
    >> 3/ as a result, the poor guy that will end up maintaining your code will
    >> positively hate you. Beware : this poor guy might as well be you.

    >
    > I still don't understand why it is a nightmare to maintain the code.
    > For my C++ project, so far so good.
    >
    > I can easily change filenames (that is class name or function name), I
    > can easily find them, I can easily move things around, all with just
    > the corresponding script command. I can navigate to the definition of
    > class and function by vim + ctags, I can see example code that calls
    > the class/function. Whenever I suspect there is a bug, I can easily go
    > to the right level of class/function in the directory hierarchy to
    > write a test case to trace down the bug without having to use gdb.
    >
    > Would you please let me why it is a nightmare?


    My current project has about 1300 source-files (luckily *not* laid out in
    your preferred way), which contain 1900 function-definitions (most probably
    even more so) and about 1700 classes. So your "approach" more than doubles
    the number of files to juggle around - in my head, in my editor, and so on.

    Not to speak about the inability to rename a function or class just in
    source-code. No, I'd also have to rename the file, causing all kinds of
    extra issues when using version-control-systems (which of course I do).

    It's simply a braindead idea. Get over it. Get rid of your "useful" scripts.
    Start learning a decent editor (emacs is mine) which allows you to deal
    with all of your perceived "problems" without making even small projects a
    nightmare of a bazillion files.

    Again: *program* in python, don't fantasize about something that's not
    there, and writing shoehorning-scripts. That's just an excuse to be
    ineffective.

    Diez
     
    Diez B. Roggisch, Nov 2, 2009
    #4
  5. Diez B. Roggisch wrote:
    > Peng Yu wrote:
    >
    >> I can navigate to the definition of
    >> class and function by vim + ctags,
    >>

    >
    > Start learning a decent editor (emacs is mine) which allows you to deal
    > with all of your perceived "problems"
    >
    > Diez
    >


    This is a declaration of war against the vi community. We won't give up,
    prepare for vengeance !
    By the way, why the hell would someone wants to limit itself to one
    function per file, file names would be probably related to the function
    name, that would make changing function name a nightmare, not mentiong
    the history issues when using version control systems. Definitely a bad
    idea.

    JM
     
    Jean-Michel Pichavant, Nov 2, 2009
    #5
  6. Bruno Desthuilliers

    Peng Yu Guest

    On Mon, Nov 2, 2009 at 9:02 AM, Jean-Michel Pichavant
    <> wrote:
    > Diez B. Roggisch wrote:
    >>
    >> Peng Yu wrote:
    >>
    >>>
    >>>  I can navigate to the definition of
    >>> class and function by vim + ctags,
    >>>

    >>
    >> Start learning a decent editor (emacs is mine) which allows you to deal
    >> with all of your perceived "problems"
    >> Diez
    >>

    >
    > This is a declaration of war against the vi community. We won't give up,
    > prepare for vengeance !
    > By the way, why the hell would someone wants to limit itself to one function
    > per file, file names would be probably related to the function name, that
    > would make changing function name a nightmare, not mentiong the history
    > issues when using version control systems. Definitely a bad idea.


    I use vi rather than emacs. I stick to vi because I stated with vi and
    I don't what to use both editors but only at an amateur level.

    With some automated script, I don't think it is a nightmare to change
    function names. I can change function names and filenames and their
    reference with a simple command.

    I'd think that this is the limitation of current version control
    system. I don't aware of any version control system that allows easy
    change of filenames. But why such features can not be implemented in
    the version control system?
     
    Peng Yu, Nov 3, 2009
    #6
  7. Bruno Desthuilliers

    Peng Yu Guest

    On Mon, Nov 2, 2009 at 7:41 PM, Lee <> wrote:
    > On Nov 2, 7:06 pm, Peng Yu <> wrote:
    >> On Mon, Nov 2, 2009 at 9:02 AM, Jean-Michel Pichavant
    >>
    >>
    >>
    >>
    >>
    >> <> wrote:
    >> > Diez B. Roggisch wrote:

    >>
    >> >> Peng Yu wrote:

    >>
    >> >>>  I can navigate to the definition of
    >> >>> class and function by vim + ctags,

    >>
    >> >> Start learning a decent editor (emacs is mine) which allows you to deal
    >> >> with all of your perceived "problems"
    >> >> Diez

    >>
    >> > This is a declaration of war against the vi community. We won't give up,
    >> > prepare for vengeance !
    >> > By the way, why the hell would someone wants to limit itself to one function
    >> > per file, file names would be probably related to the function name, that
    >> > would make changing function name a nightmare, not mentiong the history
    >> > issues when using version control systems. Definitely a bad idea.

    >>
    >> I use vi rather than emacs. I stick to vi because I stated with vi and
    >> I don't what to use both editors but only at an amateur level.
    >>
    >> With some automated script, I don't think it is a nightmare to change
    >> function names. I can change function names and filenames and their
    >> reference with a simple command.
    >>
    >> I'd think that this is the limitation of current version control
    >> system. I don't aware of any version control system that allows easy
    >> change of filenames. But why such features can not be implemented in
    >> the version control system?

    >
    > Because then the version control system would have to implicitly
    > identify the original names for files that have changed names...
    > Think about it, if you change the name of one file, the system should
    > theoretically be able to accurately identify the original filename and
    > make the corresponding changes to its database. But if you were to
    > simultaneously change the names of many files, then there's no
    > possible way for the system to determine which names belongs where...
    > I think you can see where I'm going with this.


    I don't think that this is a problem that can not be overcome. A
    simple solution might be to associate a unique identifier to each
    file, so that even the filename has been changed, the new version and
    the old version can still be identified as actually the same file.
     
    Peng Yu, Nov 3, 2009
    #7
  8. Bruno Desthuilliers

    alex23 Guest

    Peng Yu <> wrote:
    > I don't think that this is a problem that can not be overcome. A
    > simple solution might be to associate a unique identifier to each
    > file, so that even the filename has been changed, the new version and
    > the old version can still be identified as actually the same file.


    Or, again, you could work _with_ the tools you're using in the way
    they're meant to be used, rather than re-inventing the whole process
    of version control yourself.
     
    alex23, Nov 3, 2009
    #8
  9. Bruno Desthuilliers

    Peng Yu Guest

    On Mon, Nov 2, 2009 at 9:39 PM, alex23 <> wrote:
    > Peng Yu <> wrote:
    >> I don't think that this is a problem that can not be overcome. A
    >> simple solution might be to associate a unique identifier to each
    >> file, so that even the filename has been changed, the new version and
    >> the old version can still be identified as actually the same file.

    >
    > Or, again, you could work _with_ the tools you're using in the way
    > they're meant to be used, rather than re-inventing the whole process
    > of version control yourself.


    I'm not trying to reinvent a new version control. But due to this
    drawback, I avoid use a version control system. Rather, I compressed
    my source code in a tar file whenever necessary. But if a version
    control system has this capability, I'd love to use it. And I don't
    think that no version control system support this is because of any
    technical difficult but rather because of practical issue (maybe it
    takes a lot efforts to add this feature to an existing version control
    system?).
     
    Peng Yu, Nov 3, 2009
    #9
  10. En Tue, 03 Nov 2009 00:50:56 -0300, Peng Yu <> escribió:
    > On Mon, Nov 2, 2009 at 9:39 PM, alex23 <> wrote:
    >> Peng Yu <> wrote:


    >>> A simple solution might be to associate a unique identifier to each
    >>> file, so that even the filename has been changed, the new version and
    >>> the old version can still be identified as actually the same file.

    >>
    >> Or, again, you could work _with_ the tools you're using in the way
    >> they're meant to be used, rather than re-inventing the whole process
    >> of version control yourself.

    >
    > I'm not trying to reinvent a new version control. But due to this
    > drawback, I avoid use a version control system. Rather, I compressed
    > my source code in a tar file whenever necessary. But if a version
    > control system has this capability, I'd love to use it. And I don't
    > think that no version control system support this is because of any
    > technical difficult but rather because of practical issue (maybe it
    > takes a lot efforts to add this feature to an existing version control
    > system?).


    All version control systems that I know of support, at least, renaming
    files in the same directory. (Old CVS did not, but CVSNT does). svn, hg,
    darcs and bzr all have renaming support, although bzr seems to be the most
    robust, specially in non trivial cases.

    --
    Gabriel Genellina
     
    Gabriel Genellina, Nov 3, 2009
    #10
  11. On Mon, 02 Nov 2009 07:24:59 -0600, Peng Yu wrote:

    > Suppose I have class A and class B in a file, I can not easily figure
    > out which class depends on which class by a simple script.


    How about looking at the classes?

    >>> class A:

    .... pass
    ....
    >>> class B(A):

    .... pass
    ....
    >>>
    >>> B.__bases__

    (<class __main__.A at 0xb7caccbc>,)

    Classes know their own dependencies. Just ask them:

    import module
    for superclass in module.A.__bases__:
    print superclass, "is a dependency for class A"



    > However, if
    > they are in two separate files, for example B depends on A, then I will
    > have 'import A' in file B. This dependency can be easily figured out by
    > a script.



    If they are in the same file, you can just look at the class definition:

    class B(A):

    And now you know with 100% accuracy that B depends on A, instead of
    guessing that just because you import a module, that means you must have
    used a class from that module.


    > The following scenario also demonstrate why the maintenance cost is
    > lower with one class/function per file, because it decouples
    > dependences. Let's suppose class A and B are in the same file. Now I'm
    > changing class B. But while I'm changing class B, I just realize that I
    > have to change A. But since the change in B is half way done
    > (syntactical not correct), I will not be able to run the test case for
    > A, because the test case import the file that has class B. In contrast,
    > if A and B are in different files, even if B is half way done, I can
    > still run test case for A.


    Assuming A and B are independent, or that B depends on A but not the
    opposite, failing tests for B won't cause tests for A to fail. This
    doesn't change whether A and B are in the same file or not.

    The one exception to this is syntax errors. But if your project contains
    syntax errors, why are you trying to run test suites?



    --
    Steven
     
    Steven D'Aprano, Nov 3, 2009
    #11
  12. Peng Yu wrote:

    > On Mon, Nov 2, 2009 at 9:39 PM, alex23 <> wrote:
    >> Peng Yu <> wrote:
    >>> I don't think that this is a problem that can not be overcome. A
    >>> simple solution might be to associate a unique identifier to each
    >>> file, so that even the filename has been changed, the new version and
    >>> the old version can still be identified as actually the same file.

    >>
    >> Or, again, you could work _with_ the tools you're using in the way
    >> they're meant to be used, rather than re-inventing the whole process
    >> of version control yourself.

    >
    > I'm not trying to reinvent a new version control. But due to this
    > drawback, I avoid use a version control system. Rather, I compressed
    > my source code in a tar file whenever necessary. But if a version
    > control system has this capability, I'd love to use it. And I don't
    > think that no version control system support this is because of any
    > technical difficult but rather because of practical issue (maybe it
    > takes a lot efforts to add this feature to an existing version control
    > system?).


    There are those people who realize if *everything* they encounter needs
    adjustment to fit their needs, their needs need adjustment.

    Others fight an uphill battle & bicker about things not being as they want
    them.

    Don't get me wrong - innovation often comes from scratching ones personal
    itch. But you seem to be suffering from a rather bad case of
    neurodermatitis.

    Diez
     
    Diez B. Roggisch, Nov 3, 2009
    #12
  13. Ben Finney a écrit :
    > "Diez B. Roggisch" <> writes:
    >
    >> Don't get me wrong - innovation often comes from scratching ones
    >> personal itch. But you seem to be suffering from a rather bad case of
    >> neurodermatitis.

    >
    > +1 QOTW
    >

    Make it +2 QOTW !-)
     
    Bruno Desthuilliers, Nov 4, 2009
    #13
  14. Peng Yu a écrit :
    > On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
    > <> wrote:
    >> Peng Yu a écrit :
    >> (snip)
    >>> I prefer organized my code one class/function per file (i.e per module
    >>> in python). I know the majority of programmers don't use this
    >>> approach. Therefore, I'm wondering what its disadvantage is.

    >> Hmmm... As far as I'm concerned, you already answered your own question:
    >> "the majority of programmers don't use this approach".
    >>
    >> Now, for a much more practical answer:
    >> 1/ having to handle thousands of files for even a simple project is a
    >> king-size PITA for the maintainer.
    >> 2/ having to load thousands of modules will add quite a lot of overhead when
    >> actually running the code.
    >> 3/ as a result, the poor guy that will end up maintaining your code will
    >> positively hate you. Beware : this poor guy might as well be you.

    >
    > I still don't understand why it is a nightmare to maintain the code.


    Been here, done that.

    You obviously don't have enough experience with Python to understand why
    your "organization" suck. And given your apparent tendency to insist on
    imposing your own views / preconceptions on the language instead of
    learning how to use it properly (the canonical "I can write Java in any
    language" syndrom), it will probably take a long time before you get
    there - if you ever get there at all.

    My friendly (really) advice is to stop fighting the langage and start
    going with the flow.

    (snip lots of stuff that require neither "one line of code per file" nor
    fancy scripts)
     
    Bruno Desthuilliers, Nov 4, 2009
    #14
  15. Peng Yu wrote:
    > With some automated script, I don't think it is a nightmare to change
    > function names. I can change function names and filenames and their
    > reference with a simple command.
    >
    > I'd think that this is the limitation of current version control
    > system. I don't aware of any version control system that allows easy
    > change of filenames. But why such features can not be implemented in
    > the version control system?
    >


    So one function per files bring so many problems that you need an
    automated script to change one function name and complain about version
    control systems messing up with your file history.
    Still you insist on stating that this is the solution and that version
    control system have to adapt.
    It has already been told to you, and you should really consider the
    following advice:
    When everything is wrong except you, it may happen that *your* are
    somehow wrong.

    Among all the responses you got, I don't remember any one that would
    suggest you are in the right way. So what is your conclusion now ?

    JM
     
    Jean-Michel Pichavant, Nov 4, 2009
    #15
  16. Jean-Michel Pichavant wrote:

    > Peng Yu wrote:
    >> With some automated script, I don't think it is a nightmare to change
    >> function names. I can change function names and filenames and their
    >> reference with a simple command.
    >>
    >> I'd think that this is the limitation of current version control
    >> system. I don't aware of any version control system that allows easy
    >> change of filenames. But why such features can not be implemented in
    >> the version control system?
    >>

    >
    > So one function per files bring so many problems that you need an
    > automated script to change one function name and complain about version
    > control systems messing up with your file history.
    > Still you insist on stating that this is the solution and that version
    > control system have to adapt.
    > It has already been told to you, and you should really consider the
    > following advice:
    > When everything is wrong except you, it may happen that *your* are
    > somehow wrong.
    >
    > Among all the responses you got, I don't remember any one that would
    > suggest you are in the right way. So what is your conclusion now ?


    Simple: not only are the languages he uses not proper, nor the revision
    control systems, and neither the editors/IDEs out there - the whole
    communities are of course also dysfunctional, not supporting his cause :)

    Diez
     
    Diez B. Roggisch, Nov 5, 2009
    #16
  17. On Tuesday 03 November 2009, 12:52:20 Diez B. Roggisch wrote:
    > Peng Yu wrote:
    > > On Mon, Nov 2, 2009 at 9:39 PM, alex23 <> wrote:
    > >> Peng Yu <> wrote:
    > >>> I don't think that this is a problem that can not be overcome. A
    > >>> simple solution might be to associate a unique identifier to each
    > >>> file, so that even the filename has been changed, the new version and
    > >>> the old version can still be identified as actually the same file.
    > >>
    > >> Or, again, you could work _with_ the tools you're using in the way
    > >> they're meant to be used, rather than re-inventing the whole process
    > >> of version control yourself.

    > >
    > > I'm not trying to reinvent a new version control. But due to this
    > > drawback, I avoid use a version control system. Rather, I compressed
    > > my source code in a tar file whenever necessary. But if a version
    > > control system has this capability, I'd love to use it. And I don't
    > > think that no version control system support this is because of any
    > > technical difficult but rather because of practical issue (maybe it
    > > takes a lot efforts to add this feature to an existing version control
    > > system?).

    >
    > There are those people who realize if *everything* they encounter needs
    > adjustment to fit their needs, their needs need adjustment.
    >
    > Others fight an uphill battle & bicker about things not being as they
    > want them.
    >
    > Don't get me wrong - innovation often comes from scratching ones personal
    > itch. But you seem to be suffering from a rather bad case of
    > neurodermatitis.


    Diez, sorry for chiming in that lately, but while the whole thread is
    spilled over for no good reason, your QOTW remembered me on a quote of
    R.A.W., that sounds like a perfect fit:

    Whatever the Thinker thinks, the Prover will prove.

    And if the Thinker thinks passionately enough, the Prover will prove the
    thought so conclusively that you will never talk a person out of such a
    belief, even if it is something as remarkable as the notion that there is a
    gaseous vertebrate of astronomical heft ("GOD") who will spend all eternity
    torturing people who do not believe in his religion.

    From "Prometheus Rising" by Robert Anton Wilson

    Pete

    http://en.wikiquote.org/wiki/Robert_Anton_Wilson
     
    Hans-Peter Jansen, Nov 12, 2009
    #17
    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,949
    gerry
    Apr 10, 2006
  2. Razvan
    Replies:
    1
    Views:
    443
    tony vee
    Sep 10, 2004
  3. Replies:
    5
    Views:
    2,637
  4. Replies:
    0
    Views:
    373
  5. alex23
    Replies:
    6
    Views:
    302
    Bruno Desthuilliers
    Nov 2, 2009
Loading...

Share This Page