On 2020-04-11 8:38 a.m., Chris Angelico wrote:
On Sat, Apr 11, 2020 at 9:30 PM Soni L. <fakedme...@gmail.com> 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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/57Y6LDZPBVAT4Y5EVGG6ACXFOP5BWOZX/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JV6VLWWQMVVGYMLM5EV2AWPBVRG5ATPC/
Code of Conduct: http://python.org/psf/codeofconduct/
