this post was submitted on 15 Nov 2023
24 points (90.0% liked)

Python

6206 readers
12 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

October 2023

November 2023

PastJuly 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

This is a discussion on Python's forums about adding something akin to a throws keyword in python.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 10 months ago* (last edited 10 months ago) (7 children)

@sugar_in_your_tea But isn't all that possible in Python? Don't monads cover exactly what you want? Why does it need to be implemented some different way?

Also, divide by zero should be data just as well. Failing to program around having nothing to divide by is not a reason to have a program panic.

Also, having two systems for largely the same behavior doesn't seem to improve usability and clarity, in my opinion.

[–] [email protected] 1 points 10 months ago (6 children)

divide by zero should be data as well

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.

doesn't seem to improve usability

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.

[–] [email protected] 0 points 10 months ago (5 children)

@sugar_in_your_tea Since when is Python supposed to equal pseudo code? It should be easily readable, but that doesn't mean it should *equal* pseudo code.

You can either test for values being 0 before dividing, or catching an exception when it is. Especially when dividing multiple times in one function, I would go for the latter option.

[–] [email protected] 0 points 10 months ago (1 children)

@sugar_in_your_tea I don't think we should change any functionality when it comes to exception handling. Code based documentation would be great for type checking and auto-generated docs, but they can be done using annotations, not changed interfaces.

Monads are already possible, but should not be the normal way to code either. It's clunky and difficult to understand. It might work great for some scenarios, but doesn't for many others.

[–] [email protected] 1 points 10 months ago

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.

load more comments (3 replies)
load more comments (3 replies)
load more comments (3 replies)