On doing some other work, I think the logic forSTRING is also needed forFORWARDREF. I'm not sure how to resolveVALUE.

Problem for both:

fromannotationlibimportget_annotationsfromdataclassesimportdataclass@dataclassclassExample:a:list[defined_late]defined_late=intprint(get_annotations(Example.__init__))

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

ForFormat.FORWARDREF this is resolvable in the same way asSTRING. However forVALUE 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 ifinit=False that name may not be required for the__init__ annotations.

Ah, while this is resolvable forFORWARDREF - it requiresVALUE to fail orget_annotations will useVALUE instead anyway.

I'm leaning towards makingVALUE fail if any of the class annotations fail withVALUE. I can't currently think of a clean way otherwise to both makeFORWARDREF evaluate as far as possibleand not leakForwardRef values intoVALUE annotations.

Thoughts:

• With the change to collect class annotations, all of thevalues from theannotations 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 regainreturn_type and replaceannotations withannotation_fields
• I'd like to make theVALUE annotations work intest_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 Iknow I'm not completely happy with is this example from the tests²:

fromdataclassesimportdataclass,fieldfromannotationlibimportget_annotations@dataclassclassF:not_in_init:list[undefined]=field(init=False,default=None)in_init:intannos=annotationlib.get_annotations(F.__init__)# NameError

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

The ideal solution I would like for this would require an additional feature fromannotationlib 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, likefor 3.13.

@JelleZijlstra ... um, are you sure this is worth it? From anoutside 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 to3.14 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 12837c63635559873a5abddf511d38456d69617b 3.14

GH-141352 is a backport of this pull request to the3.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.