Add support for Python 3.14 #3828
Conversation
Reviewer's GuideThis PR enables Python 3.14 support by updating CI workflows and test sessions, adapting code compatibility, bumping test dependencies, extending poetry configuration, and adding a release announcement template. Class diagram for Field class Python 3.14 compatibility updateclassDiagram
class Field {
<<dataclass>>
+__init__(...)
+default
+default_factory
+doc <<added in 3.14>>
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3828 +/- ##
==========================================
- Coverage 94.76% 94.75% -0.01%
==========================================
Files 520 520
Lines 33951 33953 +2
Branches 1759 1760 +1
==========================================
Hits 32172 32172
- Misses 1497 1498 +1
- Partials 282 283 +1 🚀 New features to boost your workflow:
|
CodSpeed Performance ReportMerging #3828 will not alter performanceComparing Summary
|
Apollo Federation Subgraph Compatibility Results
Learn more: |
|
It seems that we have 2 issues here:
the new field api has an optional doc keyword, which we need to add there. Wondering if we should add
This is an issue from graphql-core, which has been fixed for 3.3.x. Should we mark |
Mmh, I don't really like doc :D I think I'd keep the same behaviour as it is now (so just passing None)
I'll make a PR to GraphQL-core, not sure when 3.3 will be released (I think it depends on GraphQL js) |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @patrick91 - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `TWEET.md:3` </location>
<code_context>
+🆕 Release $version is out! Thanks to $contributor for the PR 👏
+
+This releases adds support for Python 3.14!
+
+Get it here 👉 $release_url
</code_context>
<issue_to_address>
Typo: 'releases' should be 'release'.
It should read: 'This release adds support for Python 3.14!'.
</issue_to_address>
<suggested_fix>
<<<<<<< SEARCH
This releases adds support for Python 3.14!
=======
This release adds support for Python 3.14!
>>>>>>> REPLACE
</suggested_fix>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Greptile Summary
This PR adds support for Python 3.14 across the Strawberry GraphQL codebase through several key changes:
- Added compatibility for Python 3.14's dataclasses.Field by handling the new required 'doc' parameter
- Updated CI configuration to test against Python 3.14-dev
- Dropped Python 3.9 support and updated graphql-core dependency to 3.2.6
- Added an optional codeflash dependency group in pyproject.toml
The most significant change is in strawberry/types/field.py where a version check was added to handle Python 3.14's new required 'doc' parameter for dataclasses.Field. This change is crucial for maintaining compatibility while not affecting older Python versions.
Confidence score: 4/5
- This PR is safe to merge as it primarily adds forward compatibility
- The score of 4 reflects solid implementation but some uncertainty around testing against a development version of Python
- Files needing attention:
- strawberry/types/field.py: Verify the version check logic
- noxfile.py: Consider if dropping Python 3.9 support warrants a breaking change notice
5 files reviewed, 1 comment
Edit PR Review Bot Settings | Greptile
|
Thanks for adding the Here's a preview of the changelog: This release adds support for the upcoming Python 3.14 Here's the tweet text: |
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
| @@ -51,7 +51,8 @@ def _check_field_annotations(cls: builtins.type[Any]) -> None: | |||
|
|
|||
| https://github.com/python/cpython/blob/6fed3c85402c5ca704eb3f3189ca3f5c67a08d19/Lib/dataclasses.py#L881-L884 | |||
| """ | |||
| cls_annotations = cls.__dict__.get("__annotations__", {}) | |||
| cls_annotations = get_annotations(cls) | |||
| # TODO: do we need this? | |||
There was a problem hiding this comment.
If I'm not mistaken, on Python 3.9 or less, __annotations__ will not exist in the class unless we have at least one annotation defined in it. Even if the parent classes have one
So either this is to work around that, or because we are relying on the class' annotations instead of getting from parents as well, which now that we have get_annotations, we can probably refactor?
Let me know what you think and I can try to refactor the codebase to use get_annotations only, basing on top of this branch in another PR
There was a problem hiding this comment.
we are using get_annotations, because __annotations__ is not working anymore (or at least it is not working in the same way) in Python 3.14
There was a problem hiding this comment.
Hrmm I assumed get_annotations was going to work like I described, just saw this and now I understand its purpose.
# /// script
# dependencies = ["typing-extensions"]
# ///
from typing_extensions import get_annotations, Format
class A:
foo: str
bar: int
class B(A):
bar: "float"
baz: bool
for format in [Format.VALUE, Format.FORWARDREF, Format.STRING]:
print(f"Format: {format}")
print(get_annotations(A, format=format))
print(get_annotations(B, format=format))
print()Gives:
Format: 1
{'foo': <class 'str'>, 'bar': <class 'int'>}
{'bar': 'float', 'baz': <class 'bool'>}
Format: 3
{'foo': <class 'str'>, 'bar': <class 'int'>}
{'bar': 'float', 'baz': <class 'bool'>}
Format: 4
{'foo': 'str', 'bar': 'int'}
{'bar': 'float', 'baz': 'bool'}
So it doesn't automatically get annotations from parents, we still need to go through the MRO to get the final dict
So the reason of this TODO is indeed python 3.9, but unless we are going to use get_annotations in other places where we retrieve the annotations from the class, we still need to have this to make sure when we do cls.__annotations__ again, we get what get_annotations returned
There was a problem hiding this comment.
ah, right :) feel free to send another PR, maybe after merging this? :D
Description
Types of Changes
Issues Fixed or Closed by This PR
Checklist
Summary by Sourcery
Add support for Python 3.14 by updating test environments, applying compatibility fixes, and publishing a release announcement.
Bug Fixes:
dockeyword for dataclass fields on Python 3.14Enhancements:
CI:
Documentation: