issue: Error message for unhashable dict keys updated for Python 3.14+, but side effects handling is inconsistent.

Please ensure side effect handling is consistent for both error message branches to avoid potential loss of side effects.

Will that function be executed each time when it throws an error over and over? Is that compatible?

It seems so, you can try this script:

def test(x):
    pass

def evil(format):
    raise RuntimeError("evil")

test.__annotate__ = evil

for _ in range(3):
    try:
        print(test.__annotations__)
    except RuntimeError as error:
        print(error)

However, m_annotations seems now unused with 3.14?

No, it's used as a cache. Once __annotate__ is called, the result is stored in __annotations__, so the annotations don't have to be re-evaluated every time.

Curious, why are there plain numbers used in CPython now?

Unknown opcodes need to be marked as de-opting to themselves to support some third-party JIT compilers. See python/cpython#128045. It's probably fine to omit it for Nuitka, but I don't know what will happen if we do.

Are you saying, that all this is doing, is to create a function that returns the dictionary, just later? I thought the actual code of the annotations is to be executed delayed.

def f():
   x : something()

f()
f.__annotations__

I was assuming this will not crash when calling f().

Actually, that's ignored in all versions, but this is showing it:

class C():
   x : something()

print(C.__annotations__)

With 3.14, this crashes when .__annotations__ is looked up, and with 3.13, it does not.

With a function, it shows like this:

def f(a : something()):
   pass

print(f.__annotations__)

The re-formulation needs to use the nodes and create the updates to the __annotations__ as a function result. You need to check all uses of __annotations__ in the building code.

On second thought, that might be already correct for functions if "keys" and "values" are the ones from the function definition, not sure now, but it definitely doesn't do classes yet. And for empty annotations, I think it ought not to create a function, but instead end up passing a value. Or we check if that functions becomes a constant returner, in which case we ought to just pass its value or something, but that is optimization, which should for now maybe only result in TODOs. But a new function object per function, we don't want to hurt performance that much if we can help it in any way.

Please elaborae some more, not having these is very problematic for performance I believe

In 3.14, _PyObject_GC_TRACK now has a call to _Py_TriggerGC, which is not exported.

What's being tried there is to do minimal work under test, creating a new event loop (and releasing it?) is by definition not that. If we were to create our own on the outside and use that, no problem though.

Unfortunately, this raises an exception now, since get_event_loop no longer creates an event loop if one isn't running. It might work once I fix the exceptions in makeDiffable.

Yeah, but we actually mean to succeed in using it.

Not keeping them (the side effects) is not acceptable though, I would need to see what you actually tried there to tell, but side effects need to be of course that of the dictionaries key/values, not the dictionary building itself.

I believe this may actually be correct, and execute indeed delayed, and as such then be correct.

Does this pass any kinds of tests for it?

Yeah, this passes the tests with annotations in tests/basics.