PEP 724: Stricter Type Guards

[NeilGirdhar]

@effigies

Several people in this thread are arguing that they should not be removed.

In my opinion, we still don’t have one good example of non-strict type guards that would not be better written using strict type guards. Do you have an example from real code?

@sirosen

But there isn’t a very good rule right now for deciding what is okay to change and what isn’t, and this is part of a pattern of behavior which used to be fine but which I don’t think is long-term sustainable.

I totally agree.

@sirosen

The typing maintainer community generally wants the freedom to make these changes because they see them as better for the long-term health of the typing components of the language. But that’s not aligned with what a segment of the user community wants, which is for typing semantics to prioritize stability more highly.

Fair enough. I think that typing is not like the standard library since:

• typing does not normally affect code runtime (except in runtime introspection) and changing type errors is much lower stakes,
• type checkers can be pinned to a version even as python is upgraded, and
• typing is in its infancy and really benefits from being able to swiftly correct design errors without long and labor-intensive deprecation periods.

Anyway, I think we should probably move this discussion to the governance thread. What do you think?