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 11:34 PM, Steven D'Aprano
<steve at remove-this-cybersource.com.au> wrote:
> 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/__init__.py:
>>>
>>> from A import A  # class A from file A.py
>>> from B import B  # class B from file B.py
>>
>> 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.

The problem is when you test a package you want to 'import test.A'
rather than 'import test'. Having such __init__.py does not allow you
to import only 'test.A'. This cause artificial dependence.

>>> or better still:
>>>
>>> from a import A  # class A from file a.py
>>> from b import B  # class B from file b.py
>>
>> 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.

I'm ignoring this convention now. But I have to call a function like
glob.glob, which I also feel inconvenient.

> 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
> 'datetime'
>
>
> 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:
>
> test.A.A
>
> so when we suggest naming A.py a.py, so you can write:
>
> test.a.A
>
> you complain about that too. Frankly, I think you are just complaining
> because Python isn't C++.

I'm not complaining. I just wish there is a walkaround. In C++, I
still have to write some script to make sure the directory hierarchy
is consistent with the namespace, because C++ doesn't impose the
constraint that the directory hierarchy is the same as the namespace.
But it seems that is no such walkaround in python for my case, because
python binds namespace to directory hierarchy.

>>>> 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
>
> test/
> +--  __init__.py
> +--  A.py
> +--  B.py
>
>
> there is nothing stopping your users from doing this:
>
> import test.A as A
> import test.B as SomethingElse

First, this is a redudancy---'A' appears twice. Second, you can not do
something like the following, because name A from the two name space
is conflict.

import test.A as A
import test2.A as A


> [...]
>> 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".

I insist on having screen long functions or classes, because they have
less number of states compare with long ones. This allows me to test
all the states of them to make sure they are bug free. It is
reasonable to assume the log of the number of states of a function or
a class is proportional to it length. Hence, when a function or a
class is long, you will never be able to test all its states.

I don't have to put all related functions in a single file. With vim
and ctags, you should be able to jump to the definition of any
function or class from the place where it is used. So putting single
class/function in a file does not give me any extra 'burden' than if I
put them in the same file.