-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
[typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.11 #82786
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
Comments
The PEP-563: Postponed evaluation of annotations was introduced an opt-in feature using "from __future__ import annotations". It is scheduled to become the default in Python 4.0. I would prefer to limit the number of incompatible changes in Python 4.0: it should just a "regular" release, with a regular number of incompatible changes. The version number change is going to cause enough troubles... Would it be possible possible to enable postponed evaluation of annotations either before or after Python 4.0? For example, can we imagine to enable it by default in Python 3.9? If not, what about Python 3.10? See also the PEP-608 (Coordinated Python release) and bpo-38604 (Schedule Py_UNICODE API removal). |
IMO 3.10 would be better, since 3.9 would be too soon (it would be like a schedule for a normal deprecation). Also if we are really doing this, I think it is better to announce this soon. Also we should try to fix relevant issues related to string annotations (in typing and dataclasses), like python/typing#508, python/typing#574, https://bugs.python.org/issue37838, https://bugs.python.org/issue34776 and https://bugs.python.org/issue37948. |
We never should have mentioned 4.0 as the target date to make this the I do agree that we should start the process of deprecating the |
I am fine with modifying __future__ documentation to only modify the "Mandatory" column to remove Python 4.0, and then close this issue: -- But I like the "PEP-563: Postponed evaluation of annotations", IMHO it would be nice to get it as the default behavior :-) It's just a matter of properly organize the transition ;-) |
You can bring the deprecation schedule up on discourse or python-dev so more folks can let us know whether they'd be okay with 3.9 or 3.10. |
I started a thread on typing-sig: |
I personally like 3.10 as the target as that means users had at least 3 years to move to move over. Plus we can put a warning in the What's New for 3.9 about our plans for 3.10. |
This issue has been discussed during the Language Summit. A quick poll showed that the majority is in favor of changing the default in Python 3.9. Lukasz proposed a PEP update to propose to switch the default in Python 3.9: For me, the unclear part is which projects would be impacted if the default changes? Someone mentioned attrs, but it seems like attrs is fine: In term of workflow, I would _prefer_ to get such incompatible in the very beginning of a devcycle, rather than just before the feature freeze. But I don't think that it's a blocker issue. Technically, changes are allowed until 3.9.0 beta1. Moreover, Lukasz is the 3.9 release manager, the author of the PEP-563 and he is in favor of changing the default in 3.9 :-) |
Too bad nobody took any action here after the positive outcome of the discussion at the summit. |
I didn't understand it this way. I understood that some people were not 100% comfortable to target 3.9. The question was 3.9 or 3.10. Since the release cycle is now shorter (1 years), only targeting 3.10 is not a big deal ;-) |
We'll make this an announced 3.10 feature early on. The discussion at the Summit wasn't as clear cut to me: 35% of participants would rather see this default later than 3.9. |
Is there anyone interested to implement this change in Python 3.10? |
I opened the PR 20434 as draft, but from what I understand, there is going to be some breakage (on our test suite). I'll try to narrow it down (currently ~4 tests instead of ~20) but I dont want to prevent anyone else from working on this, so feel free to ignore my PR if you have a working test suite with a low breakage level. |
After trying to complete a patch, there are a few issues that immediately showed itself (and this might lead to not to do this in 3.10, I dont know); First one is double-forward-ref, which is usage of string-annotations when there is postponed evaluatation of annotations:
>>> import typing
>>> from __future__ import annotations
>>> def x(a: 'int'): pass
...
>>> typing.get_type_hints(x)
{'a': ForwardRef('int')} If we make annoatations feature default, this would be default behavior. The solution would be a workaround to the compiler;
static int
compiler_visit_annexpr(struct compiler *c, expr_ty annotation)
{
if (annotation->kind == Constant_kind && PyUnicode_CheckExact(annotation->v.Constant.value)) {
PyObject *text = annotation->v.Constant.value;
Py_INCREF(text);
ADDOP_LOAD_CONST_NEW(c, text);
} else {
ADDOP_LOAD_CONST_NEW(c, _PyAST_ExprAsUnicode(annotation));
}
return 1;
}
But I am not sure if this is too silly or not. The second problem is The third problem is various dataclass hacks. Like There are also some little parts that need to change. Any thoughts on these issues? |
Would you mind to elaborate why would it break some code? Consumers of annotations should already be prepared to get directly types or strings, no?
I expect that resolving has an impact on performance, whereas the caller may not use annotations at all but only cares of the number of parameters or their name. It would be resonable to not resolve annotations in signature() by default. If someone cares, maybe a new parameter can be added to resolve annotations? |
Another thought: maybe some of these issues can be considered bugs in 3.9 as well, and we should fix them there too? That might help us decide the right path forward. After all we should really encourage people to start using Final thought: I know at least the Dropbox client team, and possibly also Instagram, has already turned on |
To my knowledge, dataclasses works with There is a hack (discussed at PyCon 2018 with all of the relevant players) where it avoids importing typing to look at typing.ClassVar, but I think that code is all correct. Maybe I should just bite the bullet and import typing, since I believe importing it is faster than it used to be. |
From now on, should typing.get_type_hints automatically resolve arguments too? An example would be this; import typing
T = typing.TypeVar("T")
class Loop(typing.Generic[T]):
subloop: typing.Final["Loop[int]"]
print(typing.get_type_hints(Loop))
>>> {'subloop': typing.Final[__main__.Loop[int]]}
If we run the same code under future annotations
>>> {'subloop': typing.Final[ForwardRef('Loop[int]')]} |
I think in general it is more insightful to discuss the behavior of get_type_hints() given specific things in annotations. We generally don't write forward refs inside forward refs, like "SomeClass['int']". So maybe that code was wrong? Where did you find it? |
An example would be this cpython/Lib/test/test_typing.py Lines 2744 to 2745 in 24bddc1
class Loop: attr: Final['Loop'] to class Loop: attr: Final[Loop] or resolve everything on get_type_hints. |
There will still be a lot of code written that way, because people need compatibility with earlier versions of Python. So I think it should be fixed in get_type_hints(). |
Copy of the NEWS entry: Revert making |
I haven't followed this precisely, but I recall that when we first made PEP-563 the default, we had to fix a number of bugs in various library modules (e.g. inspect) that were only apparent when |
The major one that I'd recall is that inspect.signature() just uses whatever is in __annotations__ instead of resolving those. Now that __future__.annotations is not the default one, we can add a new option named 'resolve_annotations' and call typing.get_type_hints when activated. Here is a quick demo; from __future__ import annotations
import inspect
def foo(a: int, b: int) -> str:
...
def _get_annotations(func, **signature_opts):
signature = inspect.signature(func, **signature_opts)
return {
param.name: param.annotation
for param in signature.parameters.values()
}
print('bare: ', _get_annotations(foo))
print('annotations resolved: ', _get_annotations(foo, resolve_annotations=True)) bare: {'a': 'int', 'b': 'int'} This would be a clear feature for both PEP-563 users + people who are still using string annotations mixed with normal ones. What do you think Guido? |
May I ask, is this going forward? I installed 3.11-dev, it's not there (though __future__ claims it should be). I understand if it isn't done yet, just want to know if there's risk it will be postponed again (or even given up). |
We are still waiting a ruling on PEP-649. If it gets rejected, and no more ideas arises (before beta cut for 3.11), I guess we could move on and resolve this issue again. |
I think it would help if we could enable some future feature globally by command line option or environment variable, without modifying all source files. It would allow users to quickly test their code base for compatibility with future changes. The problem currently is that nobody bothers to add "from __future__ import ...", so we have surprises every time when try to make it by default. A tool which automatically adds or removes "from __future__ import ..." in files could help too. |
There are now multiple PEPs proposed to handle this problem differently.
The SC asked to hold this for now. So I prefer to close the issue. Please open a new issue once the SC took a decision on this topic. |
__future__.annotations
to 3.11 #25596annotations
is now "mandatory in 3.11" #25602Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: