migrating to packages
bruno.42.desthuilliers at wtf.websiteburo.oops.com
Thu Oct 4 13:34:51 CEST 2007
Hrvoje Niksic a écrit :
> Bruno Desthuilliers <bruno.42.desthuilliers at wtf.websiteburo.oops.com> writes:
>> it's quite common to use the __init__.py of the package (as
>> explained by Ben) as a facade to the internal organization of the
>> package, so you can change this internal organization without
>> breaking client code.
> We agree on that. It is the OP who *wants* to access his modules
> directly without ever naming the package.
To be exact, he wants to reorganize it's source code (splitting a file
that's getting too big AFAICT) without impacting client code. And this
is a common use case for a package - which package is given the same
name as the to-be-reorganized module, and uses imports in the
__init__.py to expose the same API as the module did.
> That is why I think he is
> missing the point of having a package in the first place.
MHO opinion is that *you* are missing *one* of the point*s* of having
>>> That way, if someone creates another module with using the same
>>> name (mymodule), it won't conflict with yours. If you don't want
>>> to change mymodule to mypackage.mymodule, why use a package in the
>>> first place?
>> Because you have too much code to keep it in a single file.
> There is no "single file", the OP already has modules A and B.
"""I have a single file with several classes, wich i want to separate"""
"""We have been using this MYCLASES in the from MYCLASES import B syntax"""
So the starting point is a single module. The OP already splitted it
indeed, and now asks how to *not* change client code's import
statements, ie how to make the newly created package exposing the same
API as the single-module did.
More information about the Python-list