This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Local import conflict with system import
Type: Stage: resolved
Components: Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: ned.deily, otrejoso
Priority: normal Keywords:

Created on 2021-05-14 15:39 by otrejoso, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
error.zip otrejoso, 2021-05-14 15:39
Messages (2)
msg393669 - (view) Author: Oscar (otrejoso) Date: 2021-05-14 15:39
Not sure if this is the right place to post this, but I stumble upon the following error.

I have the following directory structure

$ tree /F
Folder PATH listing
Volume serial number is C0000100 B8C8:3DC4
C:.
│   requirements.txt
│   run_repro.bat
│
└───testdriver
    │   jira_utils.py
    │   main.py
    │   __init__.py
    │
    └───xml
            xml_base.py
            __init__.py

and I am getting the following error when I run 

(venv) > C:\depot\bitbucket\python_bug
$ python testdriver\main.py
Traceback (most recent call last):
  File "testdriver\main.py", line 1, in <module>
    from testdriver.jira_utils import JiraUtils
  File "C:\depot\bitbucket\python_bug\testdriver\jira_utils.py", line 1, in <module>
    from jira import JIRA, JIRAError
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\jira\__init__.py", line 10, in <module>
    from jira.client import JIRA  # noqa: E402
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\jira\client.py", line 29, in <module>
    from pkg_resources import parse_version
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\pkg_resources\__init__.py", line 32, in <module>
    import plistlib
  File "C:\Python37\Lib\plistlib.py", line 65, in <module>
    from xml.parsers.expat import ParserCreate
ModuleNotFoundError: No module named 'xml.parsers'

but if I run 
(venv) otrejoso@OTREJOSO-TLALOC C:\depot\bitbucket\python_bug
$ python -c "from testdriver.jira_utils import JiraUtils"

(venv) otrejoso@OTREJOSO-TLALOC C:\depot\bitbucket\python_bug

There is no error.

I wonder if this is some kind of bug with importing packages or is it a way to fix this by importing differently?

I have attached a zip file that should be able to repro the issue. It is pretty simple since it just imports packages.
There is a run_repro.bat script to make things easier to repro

Steps of bat script:
set PYTHONPATH=.
python testdriver\main.py
python -c "from testdriver.jira_utils import JiraUtils"

Note: the zip contains the minimal files that showed the issue on bigger scale project that we have.

Thanks in advance.
msg393718 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2021-05-15 16:53
Python is behaving as documented here. The problem is that you have a package named 'xml' which conflicts with the package of the same name in the standard library (https://docs.python.org/3/library/xml.html) which may cause conflicts for other packages depending on the import search order. The documentation for sys.path (https://docs.python.org/3/library/sys.html#sys.path) explains what you are seeing:

'As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. Notice that the script directory is inserted before the entries inserted as a result of PYTHONPATH."

So, in your first example, "testdriver" will be the first entry on sys.path because the script was invoked from there; this mean 'xml' will be imported from the "testdriver" directory. But, in your second example, the script is read from the command line via the -c argument so the first sys.path entry will be '' and the current directory is 'python_bug' so now your 'xml' package is no longer found first.

This is a common pitfall and is sometimes called the "name shadowing trap" (see http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap).  The easiest and most robust solution is to avoid using package and module names that conflict with those in the standard library.
History
Date User Action Args
2022-04-11 14:59:45adminsetgithub: 88298
2021-05-15 16:53:14ned.deilysetstatus: open -> closed

nosy: + ned.deily
messages: + msg393718

resolution: not a bug
stage: resolved
2021-05-14 15:39:20otrejosocreate