cc @JelleZijlstra

further issues that seem related to the same thing

make two files, one with from __future__ import annotations, the other not. the one with future acts as a library for the one that does not have them. The annotations of a subclass declared against a base class that comes from the library are also not showing up if the base has a custom metaclass

lib.py

from __future__ import annotations

from typing import TYPE_CHECKING

class SomeMeta(type):
    if TYPE_CHECKING:
        someint: float

def make_base():
    return SomeMeta("Base", (object, ), {})

then make app.py:

from lib import make_base

Base = make_base()

class MyClass(Base):
    foo: int

import inspect

print(inspect.get_annotations(MyClass))

annotations for "foo" are lost in 3.14.0b1

# python 3.14.0b1
$ ~/.venv314/bin/python app.py 
{}

# python 3.14.0a7
$ ~/.venv314a7/bin/python app.py 
{'foo': <class 'int'>}

also suffice to say this is a way worse issue for SQLAlchemy than the conditionals thing. we have no way to work around this

I think the workaround is to not use from __future__ import annotations? Going to think about this some more; especially the fist report is unexpected. I want behavior under from __future__ import annotations to remain unchanged from 3.13, but clearly I missed something.

That's not a workaround for us, this is the SQLAlchemy library. We use modern annotations so we need from __future__ import annotations in our code since we are supporting python 3.9 through current. our users might not use this. it's not an option for the annotations to just be lost when this directive is used in some of the source files

This change seems to fix your cases:

diff --git a/Lib/annotationlib.py b/Lib/annotationlib.py
index 32b85534589..5e58e0c2dcd 100644
--- a/Lib/annotationlib.py
+++ b/Lib/annotationlib.py
@@ -1047,7 +1047,10 @@ def _get_dunder_annotations(obj):
 
     Does not return a fresh dictionary.
     """
-    ann = getattr(obj, "__annotations__", None)
+    if isinstance(obj, type):
+        ann = obj.__dict__.get("__annotations__", None)
+    else:
+        ann = getattr(obj, "__annotations__", None)
     if ann is None:
         return None
 

Unfortunately this issue brings us back to a state where cls.__annotations__ is unsafe, though no more so than before 3.14. (You'll see some interesting behavior in some of your examples if you use the __annotations__ attribute directly instead of get_annotations(); discussion in https://peps.python.org/pep-0749/#annotations-and-metaclasses .)

I'll put up a PR with this change later after I've had some time to write tests. Thanks for the early feedback, and sorry I didn't test behavior with the future import enough.

OK so I can just vendor that code right now to try to workaround? great

that's ironically pretty much the code we used in python versions prior to 3.10

this seems to be working though I am getting better results when I am using the exact version of _get_dunder_annotations that's in 3.14.0a7:

    _BASE_GET_ANNOTATIONS = type.__dict__["__annotations__"].__get__

    def _get_dunder_annotations(obj):
        if isinstance(obj, type):
            try:
                ann = _BASE_GET_ANNOTATIONS(obj)
            except AttributeError:
                # For static types, the descriptor raises AttributeError.
                return {}
        else:
            ann = getattr(obj, "__annotations__", None)
            if ann is None:
                return {}

        if not isinstance(ann, dict):
            raise ValueError(
                f"{obj!r}.__annotations__ is neither a dict nor None"
            )
        return dict(ann)

otherwise I'm getting errors on some other classes, TypeError: '>' not supported between instances of 'builtin_function_or_method' and 'int' which it's not showing exactly what it's hitting, haven't dug into it

I found another issue with TypedDict, and it seems similar to these, but is different in that the __annotations__ dictionary is simply missing super "class" elements - this is unworkable because the superclasses as declared are not actually in __mro__. Going to make a separate issue, apologies if it's the same thing

that new report is at #133701

Thanks, did you figure out anything about the TypeError: '>' not supported between instances of 'builtin_function_or_method' and 'int' thing?

I'm not able to get back to that same error and I suspect it had something to do with something internal, however, trying to find it I may have uncovered more problems here

Yeah we'll need to go back to the _BASE_GET_ANNOTATIONS hack. I'll work on it over the next few days, I want to add a similar set of test cases as in #133772 for different combinations of with/without the future.

OK the subsequent problem I'm having has to do with something related but out of the immediate scope here, I'm attempting to runtime set annotations on a class to something other than what they were, for the purposes of getting python's dataclass() function to interpret the class in a certain way, and if that class is in a hierarchy, the assignment of new annotations is not working. Admittedly setting annotations to something new is a little more of a hack, so something broke with that as of 3.14b1, so ill try to figure that out more.

That sounds like it should still work, if you can minimize the repro case please open a new issue. Thanks for all the testing!

if you just assign to __annotations__ that seems to have changed in 3.14.0b1, it has no effect now. there seems to be a new attribute __annotations_cache__ that's where the assignment goes but it's not used

Ugh that seems to be another from __future__ import annotations bug, I'll fix.

oh OK. I just put it in #133778 as you were typing this