[Andrew P. Lentvorski, Jr.]
> The code is still brittle. If score(candidate) returns None, hilarity
> ensues.
>
> ...
> If magnitude comparisons involving None raised some kind of Exception,
> this would not be an issue.
I agree, but that's also a different issue. I think people get tripped up
more often by that int < string is always true, and they'd get more relief
from that class of bug if mixing ints with strings in (at least < <= > and
>=) comparisons raised TypeError.
That plain None evaluates as false in a Boolean context is also a source of
nasty bugs. Even Guido <wink> has been bitten by that. Code like
if not thing:
...
when thing is initialized to None is common in some codebases, and can
easily do a wrong thing when the *intent* was to say "if thing has been
bound to a value other than None", i.e. if the actual intent was
if thing is not None:
...
Viewing None as "something that's not really there", it's neither true nor
false, so an exception would make sense to me here too.
But those are all incompatible changes. Adding some new singleton objects
would not have been.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4