Q on naming nested packages/modules
no.email at please.post
Tue Sep 1 18:53:08 CEST 2009
In <h7jga8$ijj$1 at reader1.panix.com> kj <no.email at please.post> writes:
>I'm having a hard time getting the hang of Python's package/module
>scheme. I'd like to find out what's considered best practice when
>dealing with the scenario illustrated below.
>The quick description of the problem is: how can I have two nested
>modules, spam.ham and spam.ham.eggs?
Following up my own post...
>From inspecting the directory structure of some of the standard
Python modules I infer the following rules:
1. the source for "leaf" modules lives in files named after them
(e.g. if x.y.z is a "leaf" module, its source code is in x/y/z.py)
2. the source for "non-leaf" modules lives in files named __init__.py
(e.g. if x.y is a "non-leaf" module, its source code lives in
the file x/y/__init__.py)
In the examples above, the module x.y is a "non-leaf" module because
there is a module x.y.z.
I.e. the "leaf"-ness of a module depends solely on whether other
modules deeper in the hierarchy are present.
An implication of all this is that if now I wanted to create a new
module x.y.z.w, this means that the previously "leaf"-module x.y.z
would become "non-leaf". In other words, I'd have to:
1. create the new directory x/y/z
2. *rename* the file x/y/z.py to x/y/z/__init__.py
3. create the file x/y/z/w.py to hold the source for the new x.y.z.w
Is the above correct? (BTW, to my Perl-pickled brain, step 2 above
is the one that causes most distress... But I think I can cope.)
More information about the Python-list