GeezerVison

On doing some other work, I think the logic for STRING is also needed for FORWARDREF. I'm not sure how to resolve VALUE.

Problem for both:

from annotationlib import get_annotations
from dataclasses import dataclass

@dataclass
class Example:
    a: list[defined_late]

defined_late = int

print(get_annotations(Example.__init__))

{'a': list[ForwardRef('defined_late', is_class=True, owner=<class '__main__.Example'>)], 'return': None}

For Format.FORWARDREF this is resolvable in the same way as STRING. However for VALUE it doesn't quite work out to do the same thing, as the annotations on the class could contain a name that doesn't exist yet - but if init=False that name may not be required for the __init__ annotations.

Ah, while this is resolvable for FORWARDREF - it requires VALUE to fail or get_annotations will use VALUE instead anyway.

I'm leaning towards making VALUE fail if any of the class annotations fail with VALUE. I can't currently think of a clean way otherwise to both make FORWARDREF evaluate as far as possible and not leak ForwardRef values into VALUE annotations.

Thoughts:

• With the change to collect class annotations, all of the values from the annotations argument are no longer used apart from the return type.
  • Perhaps _make_annotate_function should take (cls, annotation_fields, return_type) instead of (cls, annotations), where annotation_fields is just a list of relevant field names?
  • _FuncBuilder.add_fn would regain return_type and replace annotations with annotation_fields
• I'd like to make the VALUE annotations work in test_init_false_forwardref but I don't currently see a clean way to do so.

Edit: I realised changing the signature would make _add_slots simpler and is probably worthwhile.

Ok, I'm going to try to leave this alone for some review.

The only functional¹ thing I know I'm not completely happy with is this example from the tests²:

from dataclasses import dataclass, field
from annotationlib import get_annotations

@dataclass
class F:
    not_in_init: list[undefined] = field(init=False, default=None)
    in_init: int

annos = annotationlib.get_annotations(F.__init__)  # NameError 

I don't have a good approach for this. I don't think you can use FORWARDREF annotations as they are without potentially leaking actual ForwardRefs?

The ideal solution I would like for this would require an additional feature from annotationlib to provide completely unevaluated references.

Then a solution more like the original version of this PR could work.

You'll also need a NEWS entry. Since we're planning to backport to 3.14 to fix the release blocker, I think it's also worth mentioning in What's New as this will be a fairly big change in 3.14.1.

Looks like the What's New entry all that's left here. @DavidCEllis, do you want to write one? Or I can do it to help get this in.

I'm happy for you to do it. It's not something I've needed to do before so I don't actually know where it would need to go.

It would go here. For the backport, there'd be a “Notable changes” section at the end, like for 3.13.

@JelleZijlstra ... um, are you sure this is worth it? From an outside point of view this looks like a straightforward regression fix.

ping @JelleZijlstra

I plan to merge Monday or so if I don't hear back, to give enough time for a backport.

Thanks @DavidCEllis for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

Sorry, @DavidCEllis and @encukou, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 12837c63635559873a5abddf511d38456d69617b 3.14

GH-141352 is a backport of this pull request to the 3.14 branch.

Sorry for not responding here earlier, haven't been paying enough attention to GitHub.

um, are you sure this is worth it? From an outside point of view this looks like a straightforward regression fix.

Fair enough, my thinking was that this significantly changes the annotations people will see if they introspect dataclasses init functions. But our What's New documents don't seem to even have sections for changes in bugfix releases recently, so maybe it's not worth it.

But our What's New documents don't seem to even have sections for changes in bugfix releases recently, so maybe it's not worth it.

They do, at the end -- for example, https://docs.python.org/3.12/whatsnew/3.12.html#notable-changes-in-3-12-4
It's mainly used for security fixes backported to all active versions, though.