Fixed #36712 -- Evaluated type annotations lazily in template tag registration. #20340
+141
−32
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jacobtylerwalls
force-pushed
the
jtw/getfullargspec
branch
from
b057c2c to
0e1c427
Compare
…istration. Ideally, this will be reverted when an upstream solution is available for python/cpython#141560. Thanks Patrick Rauscher for the report and Augusto Pontes for the first iteration and test.
jacobtylerwalls
force-pushed
the
jtw/getfullargspec
branch
from
0e1c427 to
e79c98f
Compare
nessita
reviewed
Dec 1, 2025
Contributor
nessita
left a comment
nessita
left a comment
There was a problem hiding this comment.
Looks good, added a few naming suggestions. Thank you! 🌟
| annotation_format=annotationlib.Format.FORWARDREF, | ||
| ) | ||
|
|
||
| lock = threading.Lock() |
Contributor
There was a problem hiding this comment.
Should this lock also be inside the if PY314: guard?
| yield | ||
| return | ||
| with lock: | ||
| helper_was_already_replaced = False |
Contributor
There was a problem hiding this comment.
I would suggest using the slightly shorter:
Suggested change
| helper_was_already_replaced = False | |
| helper_was_replaced = False |
|
|
||
|
|
||
| @contextmanager | ||
| def leave_deferred_annotations_unevaluated(): |
Contributor
There was a problem hiding this comment.
How about:
Suggested change
| def leave_deferred_annotations_unevaluated(): | |
| def lazy_deferred_annotations(): |
Comment on lines
+30
to
+32
| * Fixed a bug where template tag functions relying on the Python 3.14 behavior | ||
| of deferred evaluation of type annotations could not be registered | ||
| (:ticket:`36712`). |
Contributor
There was a problem hiding this comment.
Is the bug in 5.2? or in 5.2.8? ideally we should be explicit about that. Also how about:
Suggested change
| * Fixed a bug where template tag functions relying on the Python 3.14 behavior | |
| of deferred evaluation of type annotations could not be registered | |
| (:ticket:`36712`). | |
| * Fixed a crashed in Django 5.2 and Python 3.14+ that prevented template tag | |
| functions from being registered when their type annotations required deferred | |
| evaluation (:ticket:`36712`). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trac ticket number
ticket-36712
Branch description
Python 3.14 introduces deferred evaluation of type annotations, which can make headaches around circular definitions go away.
inspect.getfullargspecwasn't updated to take the newannotation_formatarg that was provided to let inspecting libraries (us) avoid eagerly evaluating user annotations, see python/cpython#141560.One solution would have been to copy and paste the entire function--along with importing the seven or eight other symbols it needed--and do the tweak, long-term forking the implementation.
Instead, patching the module helper anticipating the change we want Python to make felt more future-proof and sufficiently self-documenting. However, I'm happy to swap this out for a copy-and-paste approach if that's preferable, but we'd want to redistribute the python license in that case, I suppose?
Ideally, this will be reverted when an upstream solution is available for python/cpython#141560.
Thanks Patrick Rauscher for the report and Augusto Pontes for the first iteration and test.
Checklist
mainbranch.