-
-
Notifications
You must be signed in to change notification settings - Fork 281
regression introduced in 2.13.0 (from 2.12.14) concerning use_cache
in astroid's cache
#2041
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sorry for taking so long to get back to this. I think it is very likely that we might refactor |
Ended up in the same place after opening #2124. I do think we should reconsider this as part of 3.0. We may look into multiprocessing first, or we may look at this part first, I'm not sure. |
Caching the sensitive part seems a lot easier to implement than multiprocessing ? I imagine it as "making sure that we can cache a function because the value returned for a particular input is always the same then adding a decorator on a function" vs "making sure that the design we have to invent can merge the result of two parallel parsing then actually implement it" ? |
I just independently arrived at the same patch. I think it's correct. #1747 didn't intend to create endless re-instantiation of modules as described in #2124. I'll open a PR and credit you @ltcmelo. Thanks! |
If modname is None (default), it's okay to use the cache; there's no point in recreating the module ad nauseum. Closes pylint-dev#2041 Co-authored-by: Leandro T. C. Melo <[email protected]>
This PR (#1747) introduced a regression in 2.13.0 (from 2.12.14). This regression causes undesired side effects — at least to me :-).
I rely on
AstroidManager.astroid_cache
to provide "special" implementations for certain modules. But the change in the PR mentioned above affects the behavior ofAstroidManager.astroid_cache
in a way that I can no longer ensure that those implementations are consistently used.(And it appears that this side effect isn't intended by the PR, since the importing module isn't the same name as the imported module.)
Reproducible steps:
Under path /user/projects/
File /user/projects/main.py
File /user/projects/proj.py:
Under path /external/repository/
This path must not be a subpath of /user/projects/.
Directory structure below:
File /external/repository/os/init.py:
File /external/repository/os/path.py:
Output of run
With:
astroid 2.12.14 (this is correct/expected "special"
os.path
)/external/repository/os/path.py
astroid 2.13.0 (the system
os.path
)/usr/local/Cellar/python/…/lib/python3.10/posixpath.py
Details
I can observe the bug in
do_import_module
whenmodname
isNone
and alsoself.modname
isNone
, which in turn leads touse_cache = False
. For instance, if you amendif mymodule.relative_to_absolute_name(modname, level) == mymodule.name:
withif modname and mymodule.relative_to_absolute_name(modname, level) == mymodule.name:
, then the bug is gone; but I'm not an astroid developer and I imagine that isn't the right place to fix the issue… it probably has a deeper root cause.The text was updated successfully, but these errors were encountered: