8000 This PR forces the use of `from __future__ import annotations` throughout cmd2 by tleonhardt · Pull Request #1444 · python-cmd2/cmd2 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

This PR forces the use of from __future__ import annotations throughout cmd2 #1444

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 10 commits into from

Conversation

tleonhardt
Copy link
Member
@tleonhardt tleonhardt commented Jun 8, 2025

This PR forces the use of from __future__ import annotations throughout cmd2.

Advantages of this include:

  • No need for Optional, can use | None instead
  • No need for Union in type hints, can use stuff like int | str instead
    • Still need to use Union for things like casts and type vars for versions prior to Python 3.10
  • No need for quotes around forward reference types
  • Allows moving imports used only for type hints under an if TYPE_CHECKING: block
  • Can theoretically improve runtime performance by delaying processing of type annotations and imports until it is needed
    • In practice this performance benefit is fairly negligible

The only real disadvantage I can see if we will probably need to leave that import in place until the oldest version we support is Python 3.14 since that is when lazy eval of type annotations is in Python by default. Either that or we might need to restore quotes around types in a couple places where they were used for forward references.

NOTE: Nearly all of the changes in this PR were done automatically by ruff after I changed the configuration for ruff in pyproject.toml.

…g.get_type_hints

Previously it was based on inspect.signature. The problem is that to Python 3.10, the inspect module doesn't have a safe way of evaluating type annotations that works equivalently both in the presence or absence of "from __future__ import annotations". Hence, any attempt at using that in an app would break cmd2.

This change adds a get_types() helper function to the cmd2.utils module which uses typing.get_type_hints() to do the introspection in a safer way.
… for this change

I first verified that this test fails on the current master branch
…ype hints that don't require things like Optional

This also supports better runtime performance by allowing imports only used for type hints to be moved under `if TYPE_CHECKING:` blocks.
Copy link
codecov bot commented Jun 8, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (491e559) to head (ce21be6).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1444      +/-   ##
==========================================
+ Coverage   98.55%   98.57%   +0.02%     
==========================================
  Files          20       20              
  Lines        5742     5753      +11     
==========================================
+ Hits         5659     5671      +12     
+ Misses         83       82       -1     
Flag Coverage Δ
unittests 98.57% <100.00%> (+0.02%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tleonhardt
Copy link
Member Author

@kmvanbrunt If you get a chance, I'd appreciate some help with manually testing this one. It seems like a good change to me, but it a large and subtle one. I want to make sure it doesn't negatively impact things like type awareness in IDEs and such.

@tleonhardt
Copy link
Member Author
tleonhardt commented Jun 9, 2025

@anselor @kotfu If either of you have experience using from __future__ import annotations, I'd appreciate hearing it. At this point I can't really see any significant downsides. So I'm soliciting feedback to make sure there aren't any hidden "gotchas" to be concerned about.

@tleonhardt
Copy link
Member Author

I did some experimentation on a large codebase I work on and found that enabling from __future__ import annotations can break frozen dataclasses in some situations, at least on versions of Python before 3.12.

Given that, I think this change would be inherently risky.

So I am closing this PR.

@tleonhardt tleonhardt closed this Jun 10, 2025
@tleonhardt tleonhardt deleted the future_annotations branch June 10, 2025 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0