In <h7jga8$ij...@reader1.panix.com> kj <no.em...@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 module 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.) kynn -- http://mail.python.org/mailman/listinfo/python-list