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