packaging

Craig Allen callen314 at gmail.com
Tue Mar 17 22:34:48 CET 2009


we have software we are putting into package form. So far, all the
code was in local py files and we imported between the modules as
you'd think.  Now with the package ("ourpackage") we are addressing
how import affects the importing module.

if "ourpackage" __init__.py itself does regular imports of the key
modules, like "ourmodule" (containing class OurClass)... it's a bit of
a pain for the user.

one imports ourpackage, and then need to get OurClass from ourmodule
still, i.e.:

  import ourpackage
  inst = ourpackage.ourmodule.OurClass()

Instead, I think we want "import package" to preserve the sort of
namespace our loose python files provided, so:

  import ourpackage
  inst = ourpackage.OurClass()

I think the way to do this, and it seems a legit use of a somewhat
dangerous form of import, to in ourpackage's __init__.py do this:

  from ourmodule import *

So that the second form works.  If anyone has a comment on that I'm
interested, either that it won't work, or to contradict my idea that a
wildcarded import is appropriate in this place as we are trying to
fill a flattened namespace.

But the reason I'm asking is that it's also been suggested that we
should include everything in a single module, so, ourpython1.py and
ourpython2.py, etc, all get moved to ourpython.py.  I very much
dislike that idea for various (probably obvious) reasons.

On the other hand I do want to adopt whatever are de facto standards
for this sort of thing (especially from the user pov but also from the
developer's)... so any comment are appreciated.  I've been using
python for a few years now but this is the first time we are forming
it in the shape of a proper package.

cheers and thanks.
-craig



More information about the Python-list mailing list