How to import standard library module instead of local directory?

前端 未结 3 1362
醉话见心
醉话见心 2021-02-20 14:43

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

相关标签:
3条回答
  • 2021-02-20 15:25

    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
    
    0 讨论(0)
  • 2021-02-20 15:28

    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…)

    0 讨论(0)
  • 2021-02-20 15:39

    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
    
    0 讨论(0)
提交回复
热议问题