The existing logic in type checkers does not deal with control flow due to try/except/else, because it's hard to reason about when an exception can or can't happen. Even if we could address this, to human readers try/except/else is an unwieldy construct to grasp compared to if/else, plus the latter allows for multiple elif clauses as well.
Actually, mypy and Pycharm (did not test others) already deal with try/except/else: ```python def as_integer(x) -> int:... x = ... try: checked_x = as_integer(x) except: ... else: reveal_type(checked_x) # note: Revealed type is 'builtins.int' ``` But I completely agree that if/else is more readable and more flexible, notably with elif.
Note that it's also easy to implement your as_integer() using a type guard:
Indeed, and it's kind of logical as the point of my example was to illustrate a replacement for type guard, the opposite replacement should be easy :-) Currently, I'm using checked cast pattern in place of type guard in my code because this is the best way I've found so far.
That's not the problem the proposal is solving.
That's not *exactly* the problem the proposal is solving, it's rather a design pattern to get around and solve the problem: instead of refining the type of variable, assign (or fail) a new variable with the refined type and use this new variable. But you seemed not enclined to this pattern, and I'm fine with that— I'm also waiting this PEP to replace my checked cast by type guards (but I would also have accepted if it was rejected to use checked cast pattern instead).
I see PEP 593 as a verbose solution to the problem "how do we use annotations for static typing and for runtime metadata simultaneously". Type guards solve a problem that's entirely in the realm of static typing, so IMO it would be an abuse of Annotated.
Fair enough. Seems my proposals are being rejected. Does the PEP need an update about them?