-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
implement from __future__ import annotations
#6117
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! One fix for the doc build.
Is fine by me, once the CI is content. |
@jepler ready to re-review, thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Consider backporting to 7.2.x. |
Backport from __future__ import annotations from #6117
For type annotation purposes, we would like to write code that uses:
This
from __future__
is part of PEP 563, which allows postponed evaluation of annotations, so that forward references work without stringifying the annotations. It is available in CPython 3.7 and up, and a lot of CPython .py code uses it. We would like to use it in code that can be used in both CPython and CircuitPython.MicroPython (and CircuitPython) already effectively implement PEP 563 in a no-op way by totally ignoring all annotations. However, MicroPython does not provide a
from __future__ import ...
at all. This PR implements a no-op__future__
module with a single memberannotations
. In CPython, members of__future__
are_Feature
objects, with version information. In this PR,annotations
is justTrue
.This adds 100 bytes to the Trinket M0 build and presumably other builds. I think this is worth it to allow compatible code.
Note that we cannot do this workaround:
because in CPython, a
from __future__
must be absolutely the first statement in a source file. We don't check this restriction, and I don't think it's necessary.