On Mar 2, 2020, at 09:26, Soni L. <fakedme...@gmail.com> wrote:
>
>> 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].)
That will help some types, but not all, with +.
But, more importantly, that only helps with (reversible) operators. It does
nothing for int(x) raising TypeError when x is not
string/byteslike/number/something with __int__. Or when it doesn’t meet the
(different) requirements for the first or the second argument of
int.from_bytes. And so on for a bunch of other methods and class methods. And
that’s just one type; the same is true for lots of other types, and plain old
functions—hundreds just in the builtins, zillions in third-party code.
The fact that you have a partial solution for a tiny subset of the problem
doesn’t help. If you want to make all operations that raise TypeError on None
instead raise NoneError, you need to come up with a way to do that, and I don’t
see any way that doesn’t involve rewriting zillions of lines of code both in
Python itself and in third-party libraries and applications.
>> > 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 .-.
This is a pretty serious problem with the proposal. Do you have an answer
beyond “oh well”, or does that mean you’re giving up on the idea, or that you
think we should go ahead with the idea even though we know it can’t work, or
what?
> Where does None do ValueError, tho? I haven't seen that one.
The most recent ones I’ve seen came from NumPy and TensorFlow, both of which
raise ValueError from some methods if you have an array of type object and have
any None values, with a message like "ValueError: None values not supported."
I’m sure there are others; this is just the first one that occurred to me.
>> > 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".
OK, but surely you must have some idea for why it might be useful or you
wouldn’t have suggested looking into it? So what is that idea?
> 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.)
Even in that case it’s still not the same thing. For example, if any of b, c,
or d is None, the none-aware operators will still raise, but your
exception-aware version will not.
So, the fact that exception-aware operators could replace some but not most
uses of none-aware operators, and would be inaccurate even when they can be
used, doesn’t seem very promising.
All in all, this whole NoneError thing seems like it could be a useful design
for a brand-new Python-like language, but I can’t see how it can be retrofitted
usefully into Python.
_______________________________________________
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/FI4WN2VB23HZMMU4WK6H4CCKNM7R3QOW/
Code of Conduct: http://python.org/psf/codeofconduct/
