NameError vs. UnboundLocalError with walrus about compgenerator HOT 3 CLOSED

I'm making a change that specifically unifies the two error messages above (a NameError that talks about a free variable), which should hopefully ensure we don't miss anything else.

Agree about just stripping off .<listcomp>.

from compgenerator.

Similarly, the qualname of lambdas defined inside a listcomp changes:

E         {'__a': {'__a': '<function __a.<locals>.<listcomp>.<lambda> at 0x...>', '__b': "'arg0'"}} != {'__a': {'__a': '<function __a.<locals>.<lambda> at 0x...>', '__b': "'arg0'"}}

from compgenerator.

It's neat to see the fuzzer actually working and finding things :)

Since UnboundLocalError is a subclass of NameError, I'm not sure this even rises to the level of needing mention in news? But happy to add an entry if you think that'd be best.

For ignoring this, we could use a regex to extract the variable name from NameError or UnboundLocalError and then simplify the representation of both errors to something simpler like "NameError: a".

Though that would also ignore a case where we changed an UnboundLocalError to a NameError -- I don't think 709 should ever do that, but I would want the fuzzer to find it if we did.

I guess we could transform all NameError to the simpler error message form, but only transform UnboundLocalError to the simpler form of NameError on the remote evalserver. Then we'd catch it in one direction but ignore it in the other.

I think the qualname change should be ignored; we should be able to just strip .<listcomp> from qualnames to do that?

from compgenerator.