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 -- http://mail.python.org/mailman/listinfo/python-list
