Re: About one class/function per module

Discussion in 'Python' started by alex23, Nov 2, 2009.

  1. alex23

    alex23 Guest

    On Nov 2, 8:11 am, Peng Yu <> wrote:
    > 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.


    You mean, what disadvantages it has _other_ than the ones you've been
    experiencing?

    Aren't those enough to warrant actually working with Python's import
    mechanism rather than against it?
     
    alex23, Nov 2, 2009
    #1
    1. Advertising

  2. alex23

    Peng Yu Guest

    On Sun, Nov 1, 2009 at 7:02 PM, alex23 <> wrote:
    > On Nov 2, 8:11 am, Peng Yu <> wrote:
    >> 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.

    >
    > You mean, what disadvantages it has _other_ than the ones you've been
    > experiencing?
    >
    > Aren't those enough to warrant actually working with Python's import
    > mechanism rather than against it?


    At least, I can use the following for now with one class/function per
    module. Unless this one class/function per module style have other
    disadvantages in term software engineering, I still can live with
    typing the class name (e.g. 'A') twice.

    import test.A
    a=test.A.A()

    So I am asking disadvantages besides python import mechanism is not
    friendly to it.
     
    Peng Yu, Nov 2, 2009
    #2
    1. Advertising

  3. alex23

    metal Guest

    On 11ÔÂ2ÈÕ, ÉÏÎç9ʱ27·Ö, Peng Yu <> wrote:
    > On Sun, Nov 1, 2009 at 7:02 PM, alex23 <> wrote:
    > > On Nov 2, 8:11 am, Peng Yu <> wrote:
    > >> 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.

    >
    > > You mean, what disadvantages it has _other_ than the ones you've been
    > > experiencing?

    >
    > > Aren't those enough to warrant actually working with Python's import
    > > mechanism rather than against it?

    >
    > At least, I can use the following for now with one class/function per
    > module. Unless this one class/function per module style have other
    > disadvantages in term software engineering, I still can live with
    > typing the class name (e.g. 'A') twice.
    >
    > import test.A
    > a=test.A.A()
    >
    > So I am asking disadvantages besides python import mechanism is not
    > friendly to it.


    I recommand you double check django project, to learn how to organize
    python project
     
    metal, Nov 2, 2009
    #3
  4. alex23

    alex23 Guest

    Peng Yu <> wrote:
    > So I am asking disadvantages besides python import mechanism is not
    > friendly to it.


    Which part of "name collisions have to be resolved somehow" isn't
    explicit enough for you?

    You can't keep saying "this works in C++" while refusing to accept
    that this is an implementation decision with Python.

    At least be honest about what you're asking for, which is confirmation
    of your existing bias.
     
    alex23, Nov 2, 2009
    #4
  5. On Sun, 01 Nov 2009 18:33:57 -0800, alex23 wrote:

    > Peng Yu <> wrote:
    >> So I am asking disadvantages besides python import mechanism is not
    >> friendly to it.

    >
    > Which part of "name collisions have to be resolved somehow" isn't
    > explicit enough for you?
    >
    > You can't keep saying "this works in C++" while refusing to accept that
    > this is an implementation decision with Python.


    Oh, it doesn't work to Peng Yu's satisfaction in C++ either. In an
    earlier email, he wrote:


    "I'm not complaining. I just wish there is a walkaround. In C++, I
    still have to write some script to make sure the directory hierarchy
    is consistent with the namespace, because C++ doesn't impose the
    constraint that the directory hierarchy is the same as the namespace.
    But it seems that is no such walkaround in python for my case, because
    python binds namespace to directory hierarchy."

    You got that? In Python, which forces the namespace and directory
    hierarchy to be the same, he wants them to be independent; in C++, which
    relaxes that restriction, he writes scripts to force them to be the same.


    [Aside: the word is "work-around" not "walk-around". Easy mistake to
    make.]



    --
    Steven
     
    Steven D'Aprano, Nov 2, 2009
    #5
  6. En Sun, 01 Nov 2009 22:27:32 -0300, Peng Yu <> escribió:
    > On Sun, Nov 1, 2009 at 7:02 PM, alex23 <> wrote:
    >> On Nov 2, 8:11 am, Peng Yu <> wrote:


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

    >>
    >> You mean, what disadvantages it has _other_ than the ones you've been
    >> experiencing?
    >>
    >> Aren't those enough to warrant actually working with Python's import
    >> mechanism rather than against it?

    >
    > At least, I can use the following for now with one class/function per
    > module. Unless this one class/function per module style have other
    > disadvantages in term software engineering, I still can live with
    > typing the class name (e.g. 'A') twice.
    >
    > import test.A
    > a=test.A.A()
    >
    > So I am asking disadvantages besides python import mechanism is not
    > friendly to it.


    You don't type the class name twice. One 'A' is a module name, the other
    'A' is the class name.
    In C++, a source file is just a compilation unit, only relevant for
    certain rules regarding visibility; it doesn't matter really in which
    source file the code is written in.
    In Python, a source file becomes a module. A module is an object: it is
    created (usually by importing it), it has attributes, there are module
    hierarchies (packages), contains other objects... A module is an important
    object in Python. You should not confuse the module with the class (or
    classes) that are defined inside it. In your example above, test.A is a
    module, test.A.A is a class; they're not the same thing. You may put one
    class per file, nobody forbids that - but remember that the class and the
    module are different objects.
    If you follow PEP8 conventions, module names are all in lowercase, and
    class names use TitleCase. This helps avoid confusion.

    --
    Gabriel Genellina
     
    Gabriel Genellina, Nov 2, 2009
    #6
  7. Gabriel Genellina a écrit :
    >>> On Nov 2, 8:11 am, Peng Yu <> wrote:

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

    (snip)
    > You may put one class per file, nobody forbids that


    But anyone having to work on your code will hate you.
     
    Bruno Desthuilliers, Nov 2, 2009
    #7
    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,895
    gerry
    Apr 10, 2006
  2. Razvan
    Replies:
    1
    Views:
    417
    tony vee
    Sep 10, 2004
  3. Replies:
    5
    Views:
    2,558
  4. Replies:
    0
    Views:
    351
  5. Bruno Desthuilliers

    Re: About one class/function per module

    Bruno Desthuilliers, Nov 2, 2009, in forum: Python
    Replies:
    16
    Views:
    419
    Hans-Peter Jansen
    Nov 12, 2009
Loading...

Share This Page