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

Steven D'Aprano steve at
Sun Nov 1 06:34:40 CET 2009

On Sat, 31 Oct 2009 22:29:12 -0500, Peng Yu wrote:

>>> 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/
>> from A import A  # class A from file 
>> from B import B  # class B from file
> I can not use the above approach as I mentioned its problem in my
> previous message.

Either I have not seen it, or I have not understood it, but I don't 
understand why you can not use this approach.

>> or better still:
>> from a import A  # class A from file
>> from b import B  # class B from file
> This artificially introduces the constraint that the file name can not
> be the same as the class/function name. There is no constraint like this
> if I can C++.

It is not a constraint, it is a convention. You are free to ignore it if 
you like.

Some people don't like writing "glob.glob" (for example). Some people 
would like to see Python ban modules with the same name as objects inside 
them, to avoid this error:

>>> import datetime
... much later
>>> from datetime import datetime
>>> datetime.datetime()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'datetime.datetime' has no attribute 

You seem to be inconsistent -- you say you want to name the file the same 
as the function in it, so you know which file to look for a function, but 
then you complain about writing:


so when we suggest naming, so you can write:


you complain about that too. Frankly, I think you are just complaining 
because Python isn't C++.

>>> 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.
> This sentence is confusing. Can you spell out what you mean?

If you supply a package


there is nothing stopping your users from doing this:

import test.A as A
import test.B as SomethingElse

> I have defined 'long' in one of my previous message. I consider a file
> long, when it does not fit in one or two screen. Basically, I want to
> get a whole picture of the file after glancing of the file.

You must only write incredibly trivial programs then.

There is more to understanding a program than understanding one single 
function. Any serious function will call other functions. To get the 
whole picture, you have to understand them too. Your requirement simply 
shifts the burden from "open one file, and read ten functions" to "open 
ten files, and read ten functions". 


More information about the Python-list mailing list