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? > 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/
