That may be a goal, but in practice code does accommodate the type checker. For example, you have to use LBYL with instance checks rather than branching with exceptions (EAFP) if you want the type checker to distinguish types in branches.
As for type guards, some patterns of usage will work, and others won’t. The point of this PEP is to allow new patterns to work, and make some old patterns incorrect.
I never said anything so extreme, so I really don’t understand this hyperbole. Let’s try to stay level-headed please.
I don’t consider it a great example because, as I said, it looks like it should have been broken into two pieces—regardless of typing, but just from the principle of the separation of concerns. But yes, it is an example. I think Mehdi’s example is much more convincing.
I don’t think it’s impossible. Maybe more projects should be added to the primer? Surveying type-checked code is an important tool in deciding type change impacts. Personally, I think it’s a lot better to gather information than it is to just imagine what code might be out there.
I think I should clarify what I meant: I’m not saying that no one is using typing. I’m saying that typing is in its infancy relative to all of the features that the typing community is waiting for. Python could stop being developed today, and I could still productively use it for a decade without wanting to switch language. Typing has come a long way, and does amazing things, but there are still features that we are desperately waiting for.
And this where my motivation lies. All changes need to balance the costs of the change:
- induced maintenance work (refactoring, etc.),
- induced false positives that break CI,
- induced false negatives that hide bugs that would otherwise be found.
—against the benefits of the change:
- providing typing expressiveness,
- making typing easier to understand,
- repairing false positives and negatives, and
- perfecting the future world of typing for future users.
So when I think about this PEP, I see a very tiny amount of induced maintenance. We have a couple examples so far that might need minor tweaks mainly to prevent false negatives (which are not a huge deal).
The benefits are significant: strict type guards are more useful, easier to understand, they repair a number of flaws in the type shed (e.g.,
isdataclass), and they make the future of typing significantly better for future users.
In case, you haven’t seen the linked issues that were added the PEP, here they are:
Many people have been asking for strict type guards. Of course that doesn’t prove that there aren’t just as many people who are perfectly happy with lax type guards. Although, it does seem that in the standard library, there is a need for strict type guards, but not for lax ones.
That’s why I like Mehdi’s proposal best. I like PEP 724’s proposal to make
TypeGuard strict. Then, if there’s enough demand, we could consider adding lax type guards with a clumsier name (or flag). This will steer users towards the strict type guards, which is probably what they want. I feel like future users will thank us for making their lives easier.
I realize we may not agree on this. I know that I tend to put a lot of weight the future. But hopefully you understand my point of view.