packaging

[Craig Allen]

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

 

[Terry Reedy]

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 *

There is also
from ourmodule import OurClass

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.

One extreme is to have a flat 'tree' with hundreds of leaves under the
top node. The other is to have one leaf per module. Either can be a
pain for the user. If your package provides a few main objects and lots
of minor objects (less important, emphasized, or used) then it makes
sense to import the main objects for direct access and sensibly group
the others. (All this regardless of file organization.)

I suggest you looks through the docs of existing packages, especially
those in some way comparable to yours, and consider the user-view
organization presented "Is this a view I sold like to use or would I
prefer otherwise?"

Good luck with whatever you have written.

Terry Jan Reedy

 

[Craig Allen]

andrew

thanks andrew, good advice, I should probably use that throughout our
code.

btw, hope the world is treating you well, long time no see...

-craig