search

davidhalter / jedi

Awesome autocompletion, static analysis and refactoring library for python
http://jedi.readthedocs.io
Other
5.78k stars 508 forks source link

name conflict with builtin modules #2019

Open sohaiberrabii opened 2 months ago

sohaiberrabii commented 2 months ago

When a library uses module names that conflicts with builtins, such as _ast.py, the import logic in https://github.com/davidhalter/jedi/blob/master/jedi/inference/compiled/subprocess/functions.py#L139 ends up using importlib.machinery.BuiltinImporter as it appears before importlib.machinery.PathFinder in sys.meta_path.

davidhalter commented 2 months ago

What's your directory structure? I would guess that this is a won't fix from our side, because the import logic probably checks sys.modules first, which loads some modules first.

IMO it's a very very bad idea anyway to overwrite top level builtins. It should be fine to use something like from jedi import _ast though.

sohaiberrabii commented 2 months ago

This came up when I tried using jedi-vim's goto on a symbol defined in the module. The module itself is from an editable installed package.

It doesn't overwrite the builtin, only shares the name. It's not a top-level module and internally the package is using relative import from ._ast import *. In the following code, the goto-command of jedi-vim will fail for both even though Foo is not defined in a builtin.

from localpackage._ast import Foo
from _ast import AST # builtin

Its a pretty rare use case, I only opened the issue in case someone else encounters it.