I have a local directory named \"calendar\" with an \"__init__.py\" file.
I want \"import calendar\" to import the standard library module calendar, and not the module d
The problem is that the current working directory (as either ''
or '.'
, depending on version/platform) is always at the top of sys.path
when you start up Python.
Using absolute imports makes no difference—that just means to look in sys.path
first, instead of looking for relative imports before falling back to sys.path
.
The right solution is obviously to either (a) rename calendar
, or (b) move it into subpackage of some other package instead of having it at the top level. Whatever your Good Reasons are, the Good Reasons for doing the right thing are likely even better.
But if you must get around this, there are a few things you can do. The simplest is to temporarily munge sys.path
:
syspath = sys.path
sys.path = [path for path in sys.path if path.strip('.')]
import calendar
sys.path = syspath
However, no matter what you do, this is going to cause huge problems. When you later try to import your local package calendar
—even if you're doing so from a completely different source file—nothing will happen, because there's already something named calendar
in sys.modules
, so that other source file will just get the stdlib calendar
module instead of your package.
So you'll also need to rename one or the other on the fly and remove it from sys.modules
. Maybe this:
syspath = sys.path
sys.path = [path for path in sys.path if path.strip('.')]
calmod = sys.modules.get('calendar')
del sys.modules['calendar']
calendar = __import__('calendar')
sys.modules['calendar'] = calmod
sys.path = syspath
And, depending on the order at which your modules get run (which may not be easily predictable, or even deterministic), there's a good chance you'll need similar hackery in the other location.
(What if you never actually need to import your local package calendar
? Well, in that case you don't have this problem… but then I can't imagine what your Good Reasons could possibly be…)