Fix: get_parso_cache_node() in jedi/parser_utils.py performs an unguarded...

[M001N]

Summary

Wrapped the get_parso_cache_node(...) call in jedi/inference/filters.py's _AbstractUsedNamesFilter.init in a try/except KeyError, falling back to self._parso_cache_node = None, mirroring the existing fallback used for the path is None branch.

Problem

davidhalter/jedi issue reference: #1888

Root Cause

get_parso_cache_node() in jedi/parser_utils.py performs an unguarded dict lookup into parso's internal parser_cache. That cache is only reliably populated for a path when diff_cache is enabled during parsing, but jedi passes diff_cache=settings.fast_parser (jedi/api/init.py, jedi/inference/imports.py). With fast_parser=False, the cache entry for an unsaved file's path may never exist, so the lookup raises KeyError. The same init in jedi/inference/filters.py already treats a missing/unavailable cache node as an expected, handled case one branch above (path is None -> self._parso_cache_node = None), confirming the rest of the class tolerates a None cache node.

Testing

PASS - all 3 tests passed (2 existing test_cache.py tests + new regression test); reproduced the KeyError crash pre-fix and confirmed it no longer occurs post-fix.

Related Issue

#1888

[davidhalter]

For the love of god, please disclose that this was done with AI!!!

Hi, I'm sorry to say this, but I decided to not work at all with AI generated pull requests/content. There are multiple reasons for this:

1. I feel like at this point it's pretty subpar to what a good engineer can create. I have received many AI generated pull requests and they all have massive problems compared to what I received from actual people. People sometimes can't fix the problems they have without AI, but I regard this as a feature: If you don't understand the problem, I don't have to review your code.
2. I love people. And I would like to interact with all of you; learn from you; teach you. But if you are simply a bridge to an LLM, I'm just wasting my time. I cannot build any form of relationship.
3. LLMs are the antithesis to what I like about programming. I like the struggle of programming. Of writing code. I love how things come together after a good coding session. This is all missing. And while some form of AI might make that skill useless in the future, it's not useless now and I would really recommend anyone to avoid LLMs for generating complex code.
4. Even for written English I generally prefer non-LLM text, because it shows something about the person. I understand that some people are incredibly non-fluent, but that's fine. Just do your best and try to learn English. Otherwise we won't have the ability to talk if we ever meet, which would be a pitty.
5. LLMs are extremely good at generating code/text that looks reasonable. I use them a lot for brainstorming, they are incredible at putting out ideas. They are bad at facts. They are really bad at thinking. The positive thing here is that you have a brain and you can use it to think. Think hard first.
6. LLMs tend to generate lots of code that is then hard to review. Try to contribute small changes first.

Thank you anyway for trying to contribute to Open Source. I would really appreciate if you avoid the usage of LLMs in my projects. It is obviously fine to use LLMs as a search/brainstorming tool with my projects, just don't use it to interact with me.

PS: As a side note I want to mention that I'm probably not the only maintainer that has a difficult relationship with LLM content. So you probably should ask first before you use LLMs for other repositories.