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

[Steven D'Aprano]

On Sat, 31 Oct 2009 16:53:50 -0500, Peng Yu wrote:

> 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.

Classes and modules are first-class objects in Python, so you can't 
necessarily tell what they are from context. I frequently have code like 
this:


def verify(test_func, objects_to_process, expected_results):
    for obj, result in zip(objects_to_process, expected_results):
        print "Testing %r..." % obj, 
        r = test_func(obj)
        if r == result:
            print "verified"
        else:
            print "expected %r but got %s" % (result, r)


objects_to_process could be a list of floats, strings, functions, 
modules, or anything else. Having a naming convention is still useful for 
distinguishing (say) factory functions from classes, or modules from 
classes.


> 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'. 


Inside test/__init__.py:

from A import A  # class A from file A.py
from B import B  # class B from file B.py


or better still:

from a import A  # class A from file a.py
from b import B  # class B from file b.py



> 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.

Of course they do.



> 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.

Define "quite long".

In Python 2.6, I have:

[steve at sylar python2.6]$ for file in */__init__.py; do echo "$file" `cat 
$file | wc -l` ; done
bsddb/__init__.py 450
compiler/__init__.py 29
ctypes/__init__.py 546
curses/__init__.py 59
distutils/__init__.py 26
email/__init__.py 123
encodings/__init__.py 157
hotshot/__init__.py 78
idlelib/__init__.py 1
json/__init__.py 318
lib2to3/__init__.py 1
logging/__init__.py 1490
multiprocessing/__init__.py 271
sqlite3/__init__.py 24
test/__init__.py 1
wsgiref/__init__.py 23
xml/__init__.py 47



With the exception of logging, I don't see any of those as quite long.



-- 
Steven