24
A proposal for java's "throws" in python: Extend type hints to cover exceptions
(discuss.python.org)
this post was submitted on 15 Nov 2023
24 points (87.5% liked)
Python
6496 readers
1 users here now
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
That's where the difference between exceptional cases comes in. Rust and Go both have the concept of a panic, which is an error that can only be caught with a special mechanism (not a try/except).
So that'll cover unexpected errors like divide by zero, out of memory, etc, and you'd handle other errors as data (e.g. record not found, validation error, etc).
I don't think Python should necessarily go as far as Go or Rust, just that handling errors like data should be an option instead of being forced to use try/except, which I find to be gross. In general, I want to use try/except if I want a stack trace, and error values when I don't.
I disagree. You should be checking your input data so the divide by zero is impossible. An invalid input error is data and it can probably be recovered from, whereas a divide by zero is something your program should never do.
If having the error is expected behavior (e.g. records/files can not exist, user data can be invalid, external service is down, etc), it's data. If it's a surprise, it's an exception and should crash.
I'm proposing that the programmer chooses. The whole design ethos around Python is that it should look like pseudocode. Pseudocode generally ignores errors, but if it doesn't, it's reasonable to express it as either an exception or data.
Documenting functions with "throws" isn't something I'd do in pseudocode because enumerating the ways something can fail generally isn't interesting. However, knowing that a function call can fail is interesting, so I think error passing in the Rust way is an interesting, subtle way of doing that.
I'm not saying we should absolutely go with monadic error returns, I'm saying that if we change error handling, I'd prefer to go that route than Java's throws, because I think documenting exceptions encourages bad use of exceptions. The code I work on already has way too many try/except blocks, I'm concerned this would cement that practice.
It's not an explicit design goal, but it explains a lot of the Zen of Python and other pushback on PIPs, so to me it's always been an unwritten design goal (be as close to pseudocode as practical, but no closer). It's also how I generally write code (start with Python "pseudocode," then decide what to use in production).
For example, from the Zen of Python:
Being clever in Python is a bad thing, just as it is in pseudocode. Python will never win awards for performance, so if you need that, you drop in something non-Python to do the expensive operations to keep the rest of the code clean and obvious.
If you think of Python as pseudocode, everything else makes a ton more sense.
Ideally, you just test for input variables outside of the function and do neither. Something like:
This throw exceptions if the preconditions fail, but those can (and should) be removed for production since their primary purpose is to inform the developer of the preconditions and catch mistakes in development. In production, you'd rely on some kind of schema validation to ensure the asserts never trigger (I'm partial to Pydantic).
So ideally you'd never expect a divide by zero or clutter your code with zero checks outside of those asserts (which shouldn't be relied on) because you've already prevented those cases from happening.
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.
Monads are only clunky because Python doesn't really support them.
And I agree, I don't think we should change existing exception handling, just allow the programmer to interact with it differently. I'd love to be able to turn exceptions into monads with a little bit of syntax. Under the hood, Python would still do the try/except, but my code would use exceptions as values instead. You'd still be able to use the older try/except explicitly just like you can express a list comprehension as a generator manually, you'd just have the option to do something else if it's cleaner in your project.
That said, exceptions as values isn't a hill I'm willing to die on, but I will push against "throws" being added, and optional chaining is a hill I'm willing to die on.