Current working directory included in import path

[sjkillen]

Describe the bug

When run with python3 -m black (used by vscode) black keeps the current working directory inside sys.path which can result in a crash if there are name conflicts between black's imports and the files in the current working directory

To Reproduce

• touch ast.py
• Run python3 -m black ast.py

Output:

python3 -m black ast.py 
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "src/black/__init__.py", line 1, in <module>
  File "/usr/lib/python3.9/asyncio/__init__.py", line 8, in <module>
    from .base_events import *
  File "/usr/lib/python3.9/asyncio/base_events.py", line 39, in <module>
    from . import coroutines
  File "/usr/lib/python3.9/asyncio/coroutines.py", line 5, in <module>
    import inspect
  File "/usr/lib/python3.9/inspect.py", line 778, in <module>
    class _ClassFinder(ast.NodeVisitor):
AttributeError: module 'ast' has no attribute 'NodeVisitor'

Expected behaviour

For the current working directory to be removed from sys.path when black is run like this.

Environment

• Black's version: black, 22.3.0 (compiled: yes)
• OS and Python version: Linux/Python 3.9.7

[JelleZijlstra]

Unfortunately I don't think this is something Black can fix; it's Python behavior. In Python 3.11 you'll be able to use the new -P option to avoid this issue.

[sjkillen]

I was thinking that

from os import getcwd
from sys import path
if getcwd() in path:
    path.remove(getcwd())

Might work but might also have unforeseen consequences and it doesn't protect files named sys.py or os.py.
I'm looking for the entrypoint though

[felix-hilden]

I'll echo Jelle. It's generally not advisable to shadow library names with your own files. Modifying the path just for that seems odd. Surely this would be a problem with most libraries that import things, right?

[felix-hilden]

I'll close this for now, since it's been established that this is not something we're willing to do, nor would the fix be the best thing for a user.