PEP 484 introduced type hints, at this time documenting exceptions was left to docstrings. I seek to suggest a reason this feature might be desirable along with how it might be used. Error handling in python does an excellent job of keeping the error-path out of the way when writing the normal flow of logic, however for larger code bases it is not always clear what exceptions may be caused by calling existing code. Since these cases are easily missed they may reach a higher level than intended ...
This is a discussion on Python’s forums about adding something akin to a throws keyword in python.
@sugar_in_your_tea Using asserts in any code except testing is frowned upon, afaik. You should use specific exceptions instead of vague unlabeled assertion errors.
You also seem to think that you’re not allowed to use exception to communicate the fact a check failed. If that’s the case, you’re seriously underusing the power of exceptions.
It sounds a lot to me like you don’t even want to use Python or think it shouldn’t be used for anything serious. Why then even argue about it?
Assertion errors should never fire, they’re merely there for documentation and catching mistakes in development. Any assertion is merely a sanity check (the value should’ve been checked before calling the function), which is why they’re disabled in production.
In fact, I conceptually like the way D makes checking preconditions and postconditions explicit. However, it’s clunky in practice imo, so asserts are usually elegant enough. I honestly only use asserts when it’s the clearest way to document the usage constraints.
you’re seriously underusing the power of exceptions
No, I use them for communicating data errors and whatnot and have a bunch of custom exceptions in my code. It’s the current Pythonic way, so that’s what I do.
However, I don’t like that pattern and find it to either hide errors or clutter my code. I much prefer the Rust style of error handling where errors are always acknowledged when they can happen, but usually handled at a higher level (like you’d do in Python, but with explicit syntax to acknowledge a call could error). I find this gives me, the programmer, a chance to consider the error case to correct logical mistakes before actually running any code, and it also improves code reviews because it’s obvious to the reviewer that the code could error. I’ve had far too many bugs caused by not knowing or forgetting a call could raise an error.
you don’t even want to use Python
When did I say that? I use it at my day job and actually argued against using Rust for our project because Python maps really well to our problem domain. Our project is hundreds of thousands of lines of Python across a dozen or more microservices, and it has served us well.
Criticizing a language doesn’t necessarily mean I don’t like it, it just means I think it could be better. Python is generally my first choice unless I know I need top performance and correctness out of the gate. For example, I’m writing a distributed lemmy competitor in Rust in my free time for various reasons (mostly I don’t want to deal with Python installers, and there’s no server component), and also building a game in Godot in GDScript (very similar to Python, even worse in perf). There are very few languages I actively dislike.
That said, in general, I prefer functional-style programming, and exceptions are one glaring wart that makes FP in Python feel bad. I want that to be better.
@sugar_in_your_tea Using asserts in any code except testing is frowned upon, afaik. You should use specific exceptions instead of vague unlabeled assertion errors.
You also seem to think that you’re not allowed to use exception to communicate the fact a check failed. If that’s the case, you’re seriously underusing the power of exceptions.
It sounds a lot to me like you don’t even want to use Python or think it shouldn’t be used for anything serious. Why then even argue about it?
Assertion errors should never fire, they’re merely there for documentation and catching mistakes in development. Any assertion is merely a sanity check (the value should’ve been checked before calling the function), which is why they’re disabled in production.
In fact, I conceptually like the way D makes checking preconditions and postconditions explicit. However, it’s clunky in practice imo, so asserts are usually elegant enough. I honestly only use asserts when it’s the clearest way to document the usage constraints.
No, I use them for communicating data errors and whatnot and have a bunch of custom exceptions in my code. It’s the current Pythonic way, so that’s what I do.
However, I don’t like that pattern and find it to either hide errors or clutter my code. I much prefer the Rust style of error handling where errors are always acknowledged when they can happen, but usually handled at a higher level (like you’d do in Python, but with explicit syntax to acknowledge a call could error). I find this gives me, the programmer, a chance to consider the error case to correct logical mistakes before actually running any code, and it also improves code reviews because it’s obvious to the reviewer that the code could error. I’ve had far too many bugs caused by not knowing or forgetting a call could raise an error.
When did I say that? I use it at my day job and actually argued against using Rust for our project because Python maps really well to our problem domain. Our project is hundreds of thousands of lines of Python across a dozen or more microservices, and it has served us well.
Criticizing a language doesn’t necessarily mean I don’t like it, it just means I think it could be better. Python is generally my first choice unless I know I need top performance and correctness out of the gate. For example, I’m writing a distributed lemmy competitor in Rust in my free time for various reasons (mostly I don’t want to deal with Python installers, and there’s no server component), and also building a game in Godot in GDScript (very similar to Python, even worse in perf). There are very few languages I actively dislike.
That said, in general, I prefer functional-style programming, and exceptions are one glaring wart that makes FP in Python feel bad. I want that to be better.