My biggest pet peeve is the complete inability to annotate a set of known exceptions that a function raises in a machine readable way. The discussion about it is quite heated.
In fairness that approach hasn’t really worked in other languages. It was so unpopular in C++ that they actually removed the feature, which is almost unheard of. Java supports it too but it’s pretty rarely used in my experience. The only place I’ve seen it used is in Android. It’s unpopular enough there that Kotlin doesn’t support it.
Interesting. I’ve never felt a need for this, and as the other reply here said it was really unpopular in other languages.
I would have guessed you would have said something about how it’s annoying to type callable arguments, and how Protocol exists but doesn’t seem that widely known.
Definitely those used to be pain points, but they do exist now so type erasure after decorator application isn’t a problem anymore, which used to be another huge one for me.
The discussion around how unpopular it was in other languages seems like such an obvious side track to me. Typing in general went out of fashion and then made a comeback when it was opt-in, why wouldn’t the same apply to exceptions? Of course I’m not wanting warnings in every func call because of a potential MemoryCorruptionError, but if a library has some set of known exceptions as a de facto part of its interface then that’s currently completely unknown to me and my static type checker.
One kinda bad example is playwright. Almost all playwright functions have the chance to raise a TimeoutError, but even if you know this you’ll probably shoot yourself in the foot at least once because it’s not the built-in TimeoutError, oh no, it’s a custom implementation from the library. If you try to simply try...except TimeoutError:, the exception will blow right by you and crash your script, you’ve got to import the correct TimeoutError.
If it was properly typed then pyright would be able to warn you that you still need to catch the other kind of TimeoutError.
It’s a bad example because like I said almost all playwright functions can raise this error so you’d get a lot of warnings, but it also demonstrates well the hidden interface problem we have right now, and it’s the most recent one that screwed me, so it’s the one I remember off the top of my head.
what do you mean by this?
My biggest pet peeve is the complete inability to annotate a set of known exceptions that a function raises in a machine readable way. The discussion about it is quite heated.
In fairness that approach hasn’t really worked in other languages. It was so unpopular in C++ that they actually removed the feature, which is almost unheard of. Java supports it too but it’s pretty rarely used in my experience. The only place I’ve seen it used is in Android. It’s unpopular enough there that Kotlin doesn’t support it.
Interesting. I’ve never felt a need for this, and as the other reply here said it was really unpopular in other languages.
I would have guessed you would have said something about how it’s annoying to type callable arguments, and how
Protocolexists but doesn’t seem that widely known.Definitely those used to be pain points, but they do exist now so type erasure after decorator application isn’t a problem anymore, which used to be another huge one for me.
The discussion around how unpopular it was in other languages seems like such an obvious side track to me. Typing in general went out of fashion and then made a comeback when it was opt-in, why wouldn’t the same apply to exceptions? Of course I’m not wanting warnings in every func call because of a potential MemoryCorruptionError, but if a library has some set of known exceptions as a de facto part of its interface then that’s currently completely unknown to me and my static type checker.
One kinda bad example is playwright. Almost all playwright functions have the chance to raise a TimeoutError, but even if you know this you’ll probably shoot yourself in the foot at least once because it’s not the built-in TimeoutError, oh no, it’s a custom implementation from the library. If you try to simply
try...except TimeoutError:, the exception will blow right by you and crash your script, you’ve got to import the correct TimeoutError. If it was properly typed then pyright would be able to warn you that you still need to catch the other kind of TimeoutError. It’s a bad example because like I said almost all playwright functions can raise this error so you’d get a lot of warnings, but it also demonstrates well the hidden interface problem we have right now, and it’s the most recent one that screwed me, so it’s the one I remember off the top of my head.