Chris Angelico writes later in thread:
> On Thu, Jul 19, 2018 at 9:55 AM, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
> Personally, I'm +0 on this. It'd be a few small wins here and there,
> nothing huge, and I could easily live without it; but it's something
> that I know some people will love.
I am 100% in sync with the reasoning, but -0 on the PEP (and only that
high because the advocates are so passionate).
To be honest, code transformations like this
> class BaseUploadObject(object):
> def find_content_type(self, filename):
> ctype, encoding = mimetypes.guess_type(filename)
> if ctype is None:
> return 'application/octet-stream'
> else:
> return ctype
to this
> class BaseUploadObject(object):
> def find_content_type(self, filename):
> ctype, encoding = mimetypes.guess_type(filename)
> return ctype ?? 'application/octet-stream'
make me cringe. Exactly one of two things is true:
1. mimetypes.guess_type guarantees that the only falsie it will ever
return is None, or
2. it doesn't.
In case 1, "ctype or 'application/octet-stream'" ALSO does the right
thing. In case 2, ONLY "ctype or 'application/octet-stream'" does the
right thing, as few callers of BaseUploadObject.find_content_type will
be prepared for "", (), [], or any variety of 0 as the return value.
This example is extreme in that by the nature of application/octet-
stream, any caller that can handle it at all will do a very reasonable
thing if find_content_type barfs up a falsie that is not None.
In many cases, of course, it would be better to (eventually) raise an
exception when a falsie escapes the expression. But in this
particular example, it's hard to imagine that is true: if the user's
expectation is violated, they'll complain, and then you can go debug.
In the meantime, the application doesn't crash and work gets done.
The prevalence of these cringe-worthy examples in advocates' posts are
why I'm basically - on the idea.
So I would like to see various examples of code where
1. in the original code, treating a falsie that is not None the same
way that None is treated is a detectable bug; and
2a. letting such falsies escape to raise exceptions somewhere else is
a good idea (and how you could know that); or
2b. catching spurious falsies and handling them here is a better idea;
or
2c. some falsies that are not None are legitimate.
That's three kinds of examples. I suspect the 2b examples are going
to be pretty "meh", because you're saving little reader cognition or
code. More important are the 2a examples, because I suspect that most
examples will fall into the same category as find_content_type: "or"
is as good as "??", and that "??" is sometimes an accident waiting to
happen due to falsie escapes (eg, when receiving objects from somebody
else's code who might not understand the contract that the only falsie
they should ever provide is None).
Steve