The difference I see is that this is a change to behaviour that is specified in the CPython documentation, for a type that’s in the CPython stdlib. I’d view that as equivalent to a change to behaviour specified in a packaging interoperability standard, which is subject to strict backward compatibility requirements.
It’s already been pointed out that this breaks real-world existing code (where a type guard is used to trigger a fast path that only applies for a particular type). If I were the writer of such code, I wouldn’t be happy with viewing the change as “type checker internal choice” - I’d be complaining to the checker that it had broken my code. And I would not be happy to be told I should refactor perfectly good, working code, just to get the previous behaviour. Honestly, I’d probably react by saying “stuff this, then” and just revert to using a
bool return type - which really isn’t helpful in any way for improving the type safety of my code.
My first reaction on seeing
TypeGuard (as a result of reviewing this PEP!) was to think “that’s neat, it would be useful to be able to say that this check confirms we have a particular type”. I didn’t think of it as particularly “far down the rabbit hole”, but rather as a way of avoiding casts and asserts (which I consider ugly, and avoid at all costs) to tell the type system things that from my perspective it “should know”.
So I think you might find more people trying out type guards than you might expect… And they may well not be experts - another disadvantage of popularity
Note that my instinctive reaction was probably to expect the existing PEP 647 semantics. Although, to be honest, I don’t think I even thought about the “return False” case, so maybe it’s better to say that I had no expectations beyond PEP 647.