On Mar 2, 2020, at 08:40, Soni L. <fakedme+py@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.
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.
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?