Python modules with identical names (i.e., reusing

问题:

Suppose I have a package that contains modules:

SWS/
  __init.py__
  foo.py
  bar.py
  time.py

and the modules need to refer to functions contained in one another. It seems like I run into problems with my time.py module since there is a standard module that goes by the same name.

For instance, in the case that my foo.py module requires both my SWS.time and the standard python time modules, I run into trouble since the interpreter will look inside the package and find my time.py modules before it comes across the standard time module.

Is there any way around this? Is this a no-no situation and should modules names not be reused?

Any solutions and opinions on package philosophy would be useful here.

回答1:

Reusing names of standard functions/classes/modules/packages is never a good idea. Try to avoid it as much as possible. However there are clean workarounds to your situation.

The behaviour you see, importing your SWS.time instead of the stdlib time, is due to the semantics of import in ancient python versions (2.x). To fix it add:

from __future__ import absolute_import

at the very top of the file. This will change the semantics of import to that of python3.x, which are much more sensible. In that case the statement:

import time

Will only refer to a top-level module. So the interpreter will not consider your SWS.time module when executing that import inside the package, but it will only use the standard library one.

If a module inside your package needs to import SWS.time you have the choice of:

• Using an explicit relative import:

  from . import time
  

• Using an absolute import:

  import SWS.time as time
  

So, your foo.py would be something like:

from __future__ import absolute_import

import time

from . import time as SWS_time

回答2:

It depends on what version of Python you're using. If your targeted Python version is 2.4 or older (in 2015, I sure hope not), then yes it would be bad practice as there is no way (without hacks) to differentiate the two modules.

However, in Python 2.5+, I think that reusing standard lib module names within a package namespace is perfectly fine; in fact, that is the spirit of PEP328.

As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path . This is called an absolute import.

The python-dev community chose absolute imports as the default because they're the more common use case and because absolute imports can provide all the functionality of relative (intra-package) imports -- albeit at the cost of difficulty when renaming package pieces higher up in the hierarchy or when moving one package inside another.

Because this represents a change in semantics, absolute imports will be optional in Python 2.5 and 2.6 through the use of from __future__ import absolute_import

SWS.time is clearly not the same thing as time and as a reader of the code, I would expect SWS.time to not only use time, but to extend it in some way.

So, if SWS.foo needs to import SWS.time, then it should use the absolute path:

# in SWS.foo

# I would suggest renaming *within*
# modules that use SWS.time so that
# readers of your code aren't confused
# with which time module you're using
from SWS import time as sws_time

Or, it should use an explicit relative import as in Bakuriu's answer:

# in SWS.foo

from . import time as sws_time

In the case that you need to import the standard lib time module within the SWS.time module, you will first need to import the future feature (only for Python 2.5+; Python 3+ does this by default):

# inside of SWS.time
from __future__ import absolute_import

import time

time.sleep(28800)  # time for bed

Note: from __future__ import absolute_imports will only affect import statements within the module that the future feature is imported and will not affect any other module (as that would be detrimental if another module depends on relative imports).

回答3:

As others have said, this is generally a bad idea.

That being said, if you're looking for potential workarounds, or a better understanding of the problem, I suggest you read the following SO questions:

• Importing from builtin library when module with same name exists

• How to access a standard-library module in Python when there is a local module with the same name?

回答4:

Yeah, really no good way around it. Try not to name your modules like standard packages. If you really want to call your module time, i'd recommend using _time.py instead. Even if there was a way to do it, it would make your code hard to read and confusing when it came to the 2 time modules.