Question about sub-packages

[Frank Millman]

Hi all

This is a follow-up to my recent question about circular imports, but on a
different subject, hence the new thread.

My application has grown to the point that it makes sense to split it up
into sub-packages.

From a certain point of view, each package can be said to have an API, not

just for third-party users of the application, but for other sub-packages
within the application. In other words, there are a number of functions that
can be called and a number of objects that can be instantiated from outside
the sub-package.

It struck me that, even though I can publish the API, it still requires
external users to know enough of the internals of the package to know which
modules to import and which objects to reference. This has two
disadvantages - it makes it more difficult to understand the API, and it
makes it more difficult for me to restructure the package internally.

An alternative is to have a dedicated API within the sub-package, in the
form of one-line functions that are called externally, and then perform
whatever action is required internally and return results as appropriate.
This is easier for users of the sub-package, and allows me to restructure
the internals of the package without causing problems.

If this makes sense, my next thought was, where is the best place to put
this API. Then I thought, why not put it in the __init__.py of the
sub-package? Then all that the users of the package have to do is import the
package, and then place calls on it directly.

I did a quick test and it seems to work. Is this a good idea, or are there
any downsides?

Thanks

Frank Millman