If you wrote the type signature of get_user
as tuple[User, None] | tuple[None, Exception]
, the assertion would not be necessary and the type checker wouldn't complain.
Python
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
They forgot the Erlang approach: throw exceptions but never catch them. If you are throwing an exception either your code is wrong or your system is bad. In either case, you should crash violently and let another instance handle the retry.
Rusty python
If only python had a throws
keyword like in Java. They got that right at least.
The words errors, go and usefull do not match in my brain.
If there is a way not to implement error handling, it would clearly be go's implemenation.
I don't really see the point of this approach. The whole bane of programming in low level languages like C is that you had to write one line of code, then 10 lines of error management for that line. Repeat until 500 lines, potentially with gotos in order to rollback previously successful operations. The result was that C was mostly error handling of function calls, and the ways to return such errors were hackish. Add reentrancy and multithreading requirements and it became a mess.
The idea of exception throwing is to forget all of this and have a separate channel where exceptions conditions flow, so the code is mean and lean and just does things, and when something goes wrong it throws a fit. If someone understands and manages that fit, great, there will be a specific handler for that, otherwise it won't. An exception is never ignored. Either it's handled or it reaches the top and stops the whole thing. With value as errors, the default is exactly the opposite.
So I don't really see a big case for going back to the old days of errors as values, because it really, really sucked.
That article isn't really advocating handling _all_ errors as values AFAICS - it just doesn't distinguish between _exceptional_ and _normal but unsuccessful_ paths.
For a wrapper around an HTTP transport, returning HTTP responses instead of raising an exception for stuff like "403 Forbidden" is probably reasonable. Their own example code is full of exceptions, though.