On 2020-04-11 8:38 a.m., Chris Angelico wrote:
On Sat, Apr 11, 2020 at 9:30 PM Soni L. firstname.lastname@example.org wrote:
alternatively, they can let their caller handle it by having the espace come from the caller.
def bar(espace=None): x = foo(espace=espace)
and then the caller is expected to handle it, *if they so choose*.
If a function just replicates down the espace parameter, how is that even slightly different from the current situation? You STILL won't be able to know where the exception came from. I am at a complete loss to understand how all of this overhead (and there is a LOT of overhead) even solves the problem.
And if a function doesn't replicate it down, what exception space should it be using? How would it know?
That just means you completely misunderstood the proposal. None would still work (and be the default). raising things in None would be the same as using python today.
the special things happen when you don't raise in None. yeah sure your function has an espace but if you don't use it... the caller won't catch those errors.
def bar(espace=None): x = foo(espace=espace) y = x['bug']
if called with an espace other than None, the explicitly declared errors from foo will be raised in the given espace. but the indexing in x['bug']? that'll just give you a KeyError in None, indicating there's a bug in bar.
you can do this. you can do all sorts of weird things. you don't have to immediately handle them. you can let them bubble up. but espaces/channels (I've been calling them both) let you be explicit about which raisers and which handlers link up to eachother. you aren't supposed to mindlessly pass espaces forward. if your function isn't supposed to raise, *don't use espaces* and don't use the new operators. that's perfectly valid, and is in fact intended. if you decide that a future version needs to be able to raise, you can add espaces then. but you wouldn't litter your codebase with espaces: you'd have an espace=None argument, and perhaps one or two statements where you pass in an espace (either with espace=espace or espace-aware operators). or you might not even accept an espace and instead just want to handle errors in the function itself but don't wanna mask bugs. all this is valid, and intended.
we'll also need operator variants. I was thinking of the following:
x.in foo bar # for attribute access x[in foo bar] # for item access x +in foo bar # for math # etc
(yes, these are very ugly. this is one of the unfortunate things of trying to retrofit this into an existing language. but they're more likely to catch bugs so I'm not worried.)
I don't think they ARE more likely to catch bugs. You're making an incredibly ugly system that still has no indication that it'll help.
maybe this should be python 4. I don't think any language's ever done Rust-like explicit error handling (i.e. avoiding the issue of swallowing bugs) using exceptions before.
That'd be because mandatory explicit error handling is identical to mandatory return value checking, which is what you get in C and plenty of other languages. Exceptions don't give you any benefit if you have to check for them after every single function call.
ChrisA _______________________________________________ Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/57Y6LD... Code of Conduct: http://python.org/psf/codeofconduct/