packaging

[Terry Reedy]

Craig Allen wrote:
> 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