On 2020-03-02 2:04 p.m., Andrew Barnert wrote:
On Mar 2, 2020, at 08:40, Soni L. <fakedme...@gmail.com> wrote:
>
> All operations on None should raise a NoneError,
So every function in every type implemented in C or in Python, whether part of
Python or third-party, that has code like this:
if not isisntance(arg, numbers.Integral):
raise TypeError(f"can only spam integers, not '{arg!r}'")
… has to change to test if arg is None and raise a different error. Otherwise,
you’re not going to catch the error from + in your example if g.foo(h) is None.
None can have __radd__ or whatnot as well, no? (read: please don't
directly raise TypeError, [redacted].)
> which should be a TypeError for backwards compatibility.
But the most common errors caused by not checking for None are AttributeError.
If you turn these into a subclass of TypeError, that won’t be backward
compatible. Others are ValueError, and that won’t be backward compatible either.
Hm. So, my original idea was to have a NoneError and MI (Multiple
Inheritance) it with TypeError, ValueError, LookupError, AttributeError,
etc. Then I checked "None[1]" and found that it raised TypeError, so I
thought all of None's unimplemented semantics provided TypeError, and
didn't realize attribute lookup was different. Oh well .-.
Where does None do ValueError, tho? I haven't seen that one.
> we can then look into merging the proposals of None-aware operators and
Exception-aware operators such that the Exception-aware operators fallback to
NoneError if no exception type is provided.
How are you going to provide an exception type for most of the None-aware
operators? For example, in a?[b][c]?[d], where do the exception types go?
Without solving that, how do you merge the two proposals?
> we should also look into making "except" default to using NoneError instead
of BaseException, with a future flag.
Why? That sounds like a terrible idea. Most uses of bare except are bad code, but
that doesn’t mean spuriously breaking all of that code and forcing people to deal
with a problem that may never have come up in their production code is a good idea.
And meanwhile, the good uses of bare except—quick&dirty code at the REPL,
exception handlers that access the current exception through other means,
etc.—would all break. And what code would benefit?
I don't know if these are good ideas, that's why I used the expression
"look into".
fwiw, assuming we had exception-aware operators, I believe a?[b][c]?[d]
wouldn't be possible, but I know a?[b]?[c]?[d] would become
a[b][c][d]?:None (or a[b][c][d]?NoneError:None to be explicit.)
_______________________________________________
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/FVKJ54J5ZGKNSUVL7XIR6HF6KMDLF7DG/
Code of Conduct: http://python.org/psf/codeofconduct/
