Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #12902 > unrolled thread

How to structure packages

Back to article view | Back to comp.lang.python

Contents

  How to structure packages bclark76 <bclark76@gmail.com> - 2011-09-07 08:56 -0700
    Re: How to structure packages John Gordon <gordon@panix.com> - 2011-09-07 16:11 +0000
      Re: How to structure packages Rafael Durán Castañeda <rafadurancastaneda@gmail.com> - 2011-09-07 19:18 +0200
    Re: How to structure packages Peter Otten <__peter__@web.de> - 2011-09-07 19:30 +0200
      Re: How to structure packages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-08 10:29 +1000
        Re: How to structure packages Chris Angelico <rosuav@gmail.com> - 2011-09-08 12:39 +1000
        Re: How to structure packages Dan Sommers <dan@tombstonezero.net> - 2011-09-08 09:51 +0000
        Re: How to structure packages Jonathan Hartley <tartley@tartley.com> - 2011-09-08 03:22 -0700
        Re: How to structure packages Nobody <nobody@nowhere.com> - 2011-09-09 01:45 +0100
          Re: How to structure packages Chris Angelico <rosuav@gmail.com> - 2011-09-09 11:37 +1000
            Re: How to structure packages Nobody <nobody@nowhere.com> - 2011-09-10 11:11 +0100
              Re: How to structure packages Chris Angelico <rosuav@gmail.com> - 2011-09-10 20:29 +1000
              Re: How to structure packages "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-09-10 08:04 -0600
          Re: How to structure packages Alec Taylor <alec.taylor6@gmail.com> - 2011-09-10 02:38 +1000
    Re: How to structure packages rantingrick <rantingrick@gmail.com> - 2011-09-07 10:56 -0700
    Re: How to structure packages "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-09-07 12:11 -0600
    Re: How to structure packages Westley Martínez <anikom15@gmail.com> - 2011-09-07 14:35 -0700

#12902 — How to structure packages

I'm learning python, and was playing with structuring packages.

Basically I want to have a package called mypackage that defines a
number of classes and functions.


so I create:

mypackage
    __init__.py
    myfunc.py
    MyClass.py


my __init__.py is blank.

my MyClass.py looks like:

import blah

class MyClass(blahblah):
    blah
    blah
    blah


then I have a run.py that looks like

from mypackage import MyClass


x = MyClass()


This doesn't work because MyClass is mypackage.MyClass.MyClass.
There's this MyClass module 'in the way'.


I'm trying to follow the rule that every file defines only one class.
I could define MyClass in __init__.py, but then what if I wanted to
define more classes in the mypackage package? My one class per file
rule goes out the window.

Is this rule wrongheaded, or is there another way to do this?


Thanks.

[toc] | [next] | [standalone]

#12904

In <2a4f542c-a8c1-46c7-9899-a3fad0940cf6@x11g2000yqc.googlegroups.com> bclark76 <bclark76@gmail.com> writes:

> mypackage
>     __init__.py
>     myfunc.py
>     MyClass.py

> from mypackage import MyClass

Try this instead:

  from mypackage.MyClass import MyClass

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#12905

Check python pep8: http://www.python.org/dev/peps/pep-0008/

And you will see than you shouldn't named modules as you did, so you 
should do something like:

mypackage
     __init__.py
     mymodule
     ...

mypackage.mymodule.MyClass

On 07/09/11 18:11, John Gordon wrote:
> In<2a4f542c-a8c1-46c7-9899-a3fad0940cf6@x11g2000yqc.googlegroups.com>  bclark76<bclark76@gmail.com>  writes:
>
>> mypackage
>>      __init__.py
>>      myfunc.py
>>      MyClass.py
>> from mypackage import MyClass
> Try this instead:
>
>    from mypackage.MyClass import MyClass
>

[toc] | [prev] | [next] | [standalone]

#12906

bclark76 wrote:

> I'm learning python, and was playing with structuring packages.

If you are coming from Jave you have to unlearn a thing or two.
 
> Basically I want to have a package called mypackage that defines a
> number of classes and functions.

> I'm trying to follow the rule that every file defines only one class.
> I could define MyClass in __init__.py, but then what if I wanted to
> define more classes in the mypackage package? My one class per file
> rule goes out the window.
> 
> Is this rule wrongheaded, 

Yes. 

> or is there another way to do this?

I recommend that you always start out with a module. Once that becomes 
unwieldy you can convert it into a package. Let's assume that

mystuff.py

contains a MyClass that you want to move into a separate file. You get the 
following files:

mystuff
    __init__.py
    descriptivename.py # MyClass here

Note that all filenames are lowercase. If you add the line

from .descriptivename import MyClass

to __init__.py you can continue to import and use MyClass with the statement

from mystuff import MyClass
m = MyClass()

or

import mystuff
m = mystuff.MyClass()

The disadvantage is of course that mystuff.descriptivename will always be 
imported, even if you don't need the part of the mystuff package defined 
there.

You may also have a look into unittest as an example of a module that was 
recently converted into a package. Classes and functions are grouped into 
submodules by their functionality rather than employing Java's mechanical 
one-class-per-file pattern.

[toc] | [prev] | [next] | [standalone]

#12927

Peter Otten wrote:

> Classes and functions are grouped into
> submodules by their functionality rather than employing Java's mechanical
> one-class-per-file pattern.

Surely it's an anti-pattern?

I suppose "one class per file" might be useful for those using an editor
with no search functionality. Other than that, is there any justification
for this rule? Any Java fans want to defend this?

If "one class per file", why not "one method per class" too? Why is the
second rule any more silly than the first?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#12942

On Thu, Sep 8, 2011 at 10:29 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Peter Otten wrote:
>
>> Classes and functions are grouped into
>> submodules by their functionality rather than employing Java's mechanical
>> one-class-per-file pattern.
>
> Surely it's an anti-pattern?

I don't think that's true; Java merely enforces one _public_ class per
source file. A file can have non-public classes, although one .class
file has only one class in it (so javac will sometimes make multiple
object files from one source file). I'm not wholly sure of the
significance of public classes, though, and whether or not it's
possible to do your logical grouping and just let them be non-public.

BTW, I am not a Java fan, and I don't have any defense prepared. I
haven't actually written any serious Java code for a number of years.
Used to use it back when IBM reckoned that Java would be the big thing
that sells OS/2.

ChrisA

[toc] | [prev] | [next] | [standalone]

#12951

On Thu, 08 Sep 2011 10:29:26 +1000, Steven D'Aprano wrote:

> I suppose "one class per file" might be useful for those using an editor
> with no search functionality. Other than that, is there any
> justification for this rule? Any Java fans want to defend this?

Back in the dark ages known as the 1980s, we had a one-C-function-per-
file rule on a project with tens of thousands of C functions.  The big 
benefit was that we always knew which source file contained which 
function.  Computers could search a directory tree much more quickly than 
that much source code.  (The exception was the so-called Information 
Cluster, a collection of functions surrounding a data store, the 
predecessor to the modern day object-with-state and/or closure).

Not a Java fan'ly yours,
Dan

[toc] | [prev] | [next] | [standalone]

#12954

On Thursday, September 8, 2011 1:29:26 AM UTC+1, Steven D'Aprano wrote:
> Steven D'Aprano wrote:
> 
> Other than that, is there any justification
> for this rule? Any Java fans want to defend this?
>
> If "one class per file", why not "one method per class" too? Why is the
> second rule any more silly than the first?


Hey. I'm not a Java fan but I'll give it a go.

One method per class is not a good idea because a class is a bunch of code that forms a coherent conceptual bundle of functionality. Often, to provide such a bundle, it requires more than one method. To split these methods across several classes would be splitting up a single coherent entity, which makes it harder to understand the purpose and identity of the entity, and more fiddly to delineate the boundary between one such entity and the next.

On the other hand, IMHO one class per file is often a good idea. Since a class is a single coherent bundle, then the natural way to split a program into files is often to divide it into these same coherent bundles. Sometimes you have two or more classes that are conceptually very tightly coupled, and it makes sense to gather them up into a single file. However, for me, this is the exception rather than the rule, so in the general case, I usually end up with code that has one class per file. It's only a rule-of-thumb though, and should be broken whenever it seems appropriate.

[toc] | [prev] | [next] | [standalone]

#12985

On Thu, 08 Sep 2011 10:29:26 +1000, Steven D'Aprano wrote:

> I suppose "one class per file" might be useful for those using an editor
> with no search functionality. Other than that, is there any justification
> for this rule? Any Java fans want to defend this?

Not a Java fan, but:

The Java compiler also acts as a "make" program. If it doesn't find
a .class file for a needed class, it will search for the corresponding
.java file and compile that. So to compile a complex program, you only
need to compile the top-level file (e.g. HelloWorld.java), and it will
compile everything which is required. No Makefile is needed, as the
relationship between classes, object files and source files is fixed.

[toc] | [prev] | [next] | [standalone]

#12989

On Fri, Sep 9, 2011 at 10:45 AM, Nobody <nobody@nowhere.com> wrote:
> The Java compiler also acts as a "make" program. If it doesn't find
> a .class file for a needed class, it will search for the corresponding
> .java file and compile that. So to compile a complex program, you only
> need to compile the top-level file (e.g. HelloWorld.java), and it will
> compile everything which is required. No Makefile is needed, as the
> relationship between classes, object files and source files is fixed.
>

If that's the entire benefit, then I think this is a rather hefty
price to pay for the elimination of a makefile. Oh wow, I can type
"javac MyClass.java" and it picks up all the others! If you're
dividing a project into multiple files already, is it that hard to
have one more that defines the relationships between the others?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#13059

On Fri, 09 Sep 2011 11:37:44 +1000, Chris Angelico wrote:

>> The Java compiler also acts as a "make" program. If it doesn't find
>> a .class file for a needed class, it will search for the corresponding
>> .java file and compile that. So to compile a complex program, you only
>> need to compile the top-level file (e.g. HelloWorld.java), and it will
>> compile everything which is required. No Makefile is needed, as the
>> relationship between classes, object files and source files is fixed.
>>
> 
> If that's the entire benefit, then I think this is a rather hefty
> price to pay for the elimination of a makefile.

It also eliminates the need for TAGS files, browser database (PDB) files,
etc. Once you know the class name, all of the filenames follow from that.

I suspect that the one-to-one correspondence between classes and .class
files is mostly technical (e.g. Java's security model). The one-to-one
correspondence between class files and source files could probably be
relaxed, but at the expense of complicating the IDE and toolchain.

I never saw it as a problem, given that Java is fundamentally class-based:
there are no global variables or functions, only classes.

[toc] | [prev] | [next] | [standalone]

#13061

On Sat, Sep 10, 2011 at 8:11 PM, Nobody <nobody@nowhere.com> wrote:
> I suspect that the one-to-one correspondence between classes and .class
> files is mostly technical (e.g. Java's security model). The one-to-one
> correspondence between class files and source files could probably be
> relaxed, but at the expense of complicating the IDE and toolchain.

One class per object file isn't a problem - you can always .jar your
classes if the proliferation of small files bothers you, and then it's
just a different way of indexing the mound of code.

One class per source file complicates the human's view in order to
simplify the tools'. Not sure that's really worthwhile.

> I never saw it as a problem, given that Java is fundamentally class-based:
> there are no global variables or functions, only classes.

Yeah... of course you can easily simulate globals with static members
in a dedicated class, but it's slower. THIS, though, is where Java's
security model comes in - you can assign security X to Globals1.class
and security Y to Globals2.class, rather than trying to juggle
security issues in a monolithic "globals" namespace. IMHO it's not
worth the hassle, though. I'd rather just have globals.

ChrisA

[toc] | [prev] | [next] | [standalone]

#13071

On 9/10/2011 4:11 AM, Nobody wrote:
> On Fri, 09 Sep 2011 11:37:44 +1000, Chris Angelico wrote:
>
>>> The Java compiler also acts as a "make" program. If it doesn't find
>>> a .class file for a needed class, it will search for the corresponding
>>> .java file and compile that. So to compile a complex program, you only
>>> need to compile the top-level file (e.g. HelloWorld.java), and it will
>>> compile everything which is required. No Makefile is needed, as the
>>> relationship between classes, object files and source files is fixed.
>>>
>> If that's the entire benefit, then I think this is a rather hefty
>> price to pay for the elimination of a makefile.
> It also eliminates the need for TAGS files, browser database (PDB) files,
> etc. Once you know the class name, all of the filenames follow from that.
>
> I suspect that the one-to-one correspondence between classes and .class
> files is mostly technical (e.g. Java's security model). The one-to-one
> correspondence between class files and source files could probably be
> relaxed, but at the expense of complicating the IDE and toolchain.
>
> I never saw it as a problem, given that Java is fundamentally class-based:
> there are no global variables or functions, only classes.
>
Sure there are no global variables, but having one class per file is one 
of the big things I hate about Java. Sure it keeps things organized, but 
that's a bit to much for me.



-- 

Take care,
Ty
Web: http://tds-solutions.net
The Aspen project: a light-weight barebones mud engine
http://code.google.com/p/aspenmud

Sent from my toaster.

[toc] | [prev] | [next] | [standalone]

#13029

Kayode: Are the number of pages in that tutorial planned?

:P

> On Sat, Sep 10, 2011 at 1:57 AM, Kayode Odeyemi <dreyemi@gmail.com> wrote:
>> You might want to have a look at this:
>> http://www.ccs.neu.edu/home/matthias/htdc.html
>>
>> On Fri, Sep 9, 2011 at 2:37 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>>
>>> On Fri, Sep 9, 2011 at 10:45 AM, Nobody <nobody@nowhere.com> wrote:
>>> > The Java compiler also acts as a "make" program. If it doesn't find
>>> > a .class file for a needed class, it will search for the corresponding
>>> > .java file and compile that. So to compile a complex program, you only
>>> > need to compile the top-level file (e.g. HelloWorld.java), and it will
>>> > compile everything which is required. No Makefile is needed, as the
>>> > relationship between classes, object files and source files is fixed.
>>> >
>>>
>>> If that's the entire benefit, then I think this is a rather hefty
>>> price to pay for the elimination of a makefile. Oh wow, I can type
>>> "javac MyClass.java" and it picks up all the others! If you're
>>> dividing a project into multiple files already, is it that hard to
>>> have one more that defines the relationships between the others?
>>>
>>> Chris Angelico
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>>
>> --
>> Odeyemi 'Kayode O.
>> http://www.sinati.com. t: @charyorde
>>
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>

[toc] | [prev] | [next] | [standalone]

#12907

On Sep 7, 10:56 am, bclark76 <bclar...@gmail.com> wrote:
> I'm learning python, and was playing with structuring packages.
>
> Basically I want to have a package called mypackage that defines a
> number of classes and functions.
>
> so I create:
>
> mypackage
>     __init__.py
>     myfunc.py
>     MyClass.py

Don't tell me you create a module called myfunc.py??? Stuff that
function in __init__! Also don't name modules MyClass either. Both the
spelling and grammar is incorrect. ALL modules use lowercase (and only
integrate underscores in the most dire of need!)

geom
   __init__.py
   vector3d.py
   point3d.py
   transformation.py

from geom.transformation import Transformation
from geom.vector3d import Vector3d
from geom.point3d import Point3d

or alternatively:

geom
   __init__.py
       from __vector3d import Vector3d
       from __point3d import Point3d
       from __transformation import Transformation
   __vector3d.py
   __point3d.py
   __transformation.py

from geom import Transformation
from geom import Vector3d
from geom import Point3d

Although this method can be brittle due to the fact that one buggy
module can break all the imported code in the __init__ module. I
usually opt for specifying the module in the import path.

[toc] | [prev] | [next] | [standalone]

#12908

On 9/7/2011 9:56 AM, bclark76 wrote:
> I'm learning python, and was playing with structuring packages.
>
> Basically I want to have a package called mypackage that defines a
> number of classes and functions.
>
>
> so I create:
>
> mypackage
>      __init__.py
>      myfunc.py
>      MyClass.py
>
>
> my __init__.py is blank.
>
> my MyClass.py looks like:
>
> import blah
>
> class MyClass(blahblah):
>      blah
>      blah
>      blah
>
>
> then I have a run.py that looks like
>
> from mypackage import MyClass
>
>
> x = MyClass()
>
>
> This doesn't work because MyClass is mypackage.MyClass.MyClass.
> There's this MyClass module 'in the way'.
>
You can use the __init__.py to promote that class up. so:
from myclass import myclass
So that means that myclass will just be in mypackage.myclass, and thus 
your from mypackage import myclass would work perfectly. I'm not sure if 
this is how you're supposed to do it, but it works.

> I'm trying to follow the rule that every file defines only one class.
> I could define MyClass in __init__.py, but then what if I wanted to
> define more classes in the mypackage package? My one class per file
> rule goes out the window.
>
> Is this rule wrongheaded, or is there another way to do this?
>
>
> Thanks.
>


-- 

Take care,
Ty
Web: http://tds-solutions.net

Sent from my toaster.

[toc] | [prev] | [next] | [standalone]

#12915

First of all MyClass.py should be renamed to myclass.py.  Module names
should be lowercase.  Secondly, put this in __init__.py:

    from .myclass import MyClass

and there you go.

On Wed, Sep 07, 2011 at 08:56:32AM -0700, bclark76 wrote:
> I'm learning python, and was playing with structuring packages.
> 
> Basically I want to have a package called mypackage that defines a
> number of classes and functions.
> 
> 
> so I create:
> 
> mypackage
>     __init__.py
>     myfunc.py
>     MyClass.py
> 
> 
> my __init__.py is blank.
> 
> my MyClass.py looks like:
> 
> import blah
> 
> class MyClass(blahblah):
>     blah
>     blah
>     blah
> 
> 
> then I have a run.py that looks like
> 
> from mypackage import MyClass
> 
> 
> x = MyClass()
> 
> 
> This doesn't work because MyClass is mypackage.MyClass.MyClass.
> There's this MyClass module 'in the way'.
> 
> 
> I'm trying to follow the rule that every file defines only one class.
> I could define MyClass in __init__.py, but then what if I wanted to
> define more classes in the mypackage package? My one class per file
> rule goes out the window.
> 
> Is this rule wrongheaded, or is there another way to do this?
> 
> 
> Thanks.
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web