How to import only one module in a package when the package __init__.py has already imports the modules?

[Peng Yu]

On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2009-10-31 15:31 PM, Peng Yu wrote:
>
>> The original problem comes from the maintenance of the package. When A
>> and B are large classes, it is better to put them in separate files
>> under the directory 'test' than put them in the file 'test.py'. The
>> interface 'test.A' is used by end users. However, there will be a
>> problem if 'import test' is used for developers, because both A and B
>> are imported, which cause dependence between A and B. For example,
>> during the modification of B (not finished), 'import A' would not
>> work. This is means that modifications of A and B are not independent,
>> which cause a lot of problem when maintaining the package.
>
> To be frank, that development process is going to cause you a lot of
> problems well beyond these import entanglements. Developers should have
> their own workspace! They shouldn't push things into production until the
> system is working. Checking something into source control shouldn't
> automatically deploy things into production.

I don't quite agree with your opinion. But please don't take it too personaly.

Even in the developer's work space, it is possible to change multiple
classes simultaneously. So the import entanglement problem still
exists.

>> Naming the filename different from the class is a solution, but it is
>> a little bit annoying.
>>
>> I'm wondering how people handle this situation when they have to
>> separate a module into multiple modules.
>
> Even if we organize things along the lines of "one class per module", we use
> different capitalization conventions for modules and classes. In part, this
> helps solve your problem, but it mostly saves the developer thought-cycles
> from having to figure out which you are referring to when reading the code.

I know that multiple classes or functions are typically defined in one
file (i.e. module in python). However, I feel this make the code not
easy to read. Therefore, I insist on one class or function per file
(i.e module in python).

When one class per module is strictly enforced, there will be no need
to have different capitalization conventions for modules and classes.
Developers should be able to tell whether it is a class or a module
from the context.

In my question, module A and B exist just for the sake of
implementation. Even if I have module A and B, I don't want the user
feel the existence of module A and B. I want them feel exact like
class A and B are defined in module 'test' instead of feeling two
modules A and B are in package 'test'. I know that module names should
be in lower cases, in general. However, it is OK to have the module
name capitalized in this case since the end users don't see them.

In C++, what I am asking can be easily implemented, because the
namespace and the directory hierachy is not bind to each other.
However, the binding between the namespace and the directory hierachy
make this difficult to implement. I don't know if it is not
impossible, but I'd hope there is a way to do so.

> Personally, I like to keep my __init__.py files empty such that I can import
> exactly what I need from the package. This allows me to import exactly the
> module that I need. In large packages with extension modules that can be
> expensive to load, this is useful. We usually augment this with an api.py
> that exposes the convenient "public API" of the package, the A and B classes
> in your case.

I looked at python library, there are quite a few __init__.py files
are not empty. In fact, they are quite long. I agree with you that
'__init__.py' should not be long. But I'm wondering why in python
library __init__.py are quite long.