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
As the rest says, the best option is to rename the calendar module into a new module not used by standard library.
But as a workaround if that's not possible, you could create a another module (visible in the syspath) outside the directory where the local calendar.py
file is placed.
So if you have a hierarchy like this:
project/
__init__.py
app1/
__init__.py
calendar.py
module_in_which_i_want_to_use_python_std_calendar.py
You could create a new module named std_calendar.py
outside apps (outside calendar.py is placed). In this file you could import calendar (this will be standard calendar module)
from calendar import *
And the hierarchy would be:
project/
__init__.py
std_calendar.py
app1/
__init__.py
calendar.py
module_in_which_i_want_to_use_python_std_calendar.py
In module_in_which_i_want_to_use_python_std_calendar.py
you could use standard calendar with:
from project import std_calendar as calendar
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…)
You could modify sys.path, import the package, then restore sys.path
to its original value.
import sys
original_path = sys.path
sys.path = original_path[1:]
import calendar
sys.path = original_path