Skip to content

Conversation

@anuraaga
Copy link
Collaborator

@anuraaga anuraaga commented Dec 3, 2025

From what I understand it's fairly common convention to always use future annotations to have type safety with minimizing runtime overhead. It's the default from Python 3.14 - actually I came up with this when I realized now it's relatively easy writing code that works on 3.14 but crashes on others due to the differing behavior (almost always caught by unit tests but just a developer convenience too).

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>
Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>
@anuraaga anuraaga changed the title Always import future annotations Automatically add future annotations import Dec 3, 2025
@stefanvanburen
Copy link
Member

I'm not sure I know enough about those annotations, but it seems like the current plan is that they'll eventually be deprecated and emit warnings?: https://peps.python.org/pep-0749/#the-future-of-from-future-import-annotations. Would the plan be to remove them when we stop supporting e.g. Python 3.13?

@anuraaga
Copy link
Collaborator Author

anuraaga commented Dec 3, 2025

Yeah that would be the time. That doc seems to acknowledge the common use of these as it seems there wouldn't be a deprecation until 3.13 is EoL, or even longer past that based on the community. That's many many years away and more lenient than most deprecations plans.

However, many libraries are already using from future import annotations as an elegant way to enable unrestricted forward references in their annotations. If we deprecate the future import immediately, it would be impossible for these libraries to use unrestricted forward references on all supported Python versions while avoiding deprecation warnings

# Format Python files
format:
uv run ruff check --fix .
uv run ruff check --fix --unsafe-fixes --exit-zero .
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to comment on this. I have been using unsafe-fixes for a long time and find it great, zero times has it done a wrong fix. That's probably because I work with well behaved code without weird side effects, but I think it applies here too. In the off chance it does do something wrong, manually fixing it would be relatively easy.

@anuraaga anuraaga added the enhancement New feature or request label Dec 4, 2025
@anuraaga anuraaga merged commit aa70926 into connectrpc:main Dec 5, 2025
25 of 43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants