Hrvoje Niksic a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> 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 packages. >>> 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. Let's see: """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. -- http://mail.python.org/mailman/listinfo/python-list
