PEP649 means that PEP563 will see *more* usage, not less, and will break runtime typecheckers

Typing
2

Apologies, I struggle to read text that leycec writes. Thanks for opening a discussion — if I understand correctly, the concern is something like:

  1. The PEP 649 behaviour is enabled by default in 3.13
  2. Someone writes a forward ref. When they run tests against 3.12, they get a NameError, so they add from __future__ import annotations to fix (or quote their annotations)
  3. If a user of that code is doing runtime type checking, and it’s one of the cases where eval works badly, that user is unhappy

Maybe I’m missing something obvious, but I’m confused how this is much worse than today. Step 2 plays out exactly the same as it would today. from __future__ import annotations is widely used enough that every runtime type checker needs to have basic support for it.

Anyway, I think it’s fairly likely that PEP 649 behaviour does not end up being enabled by default in 3.13. The SC at the time a) appeared unsure about that point and ended up polling, b) wanted it to land early in the lifecycle of 3.13. If it doesn’t land relatively soon, I wouldn’t be surprised if PEP 649 remains __future__ gated.

9 Likes