Chris Angelico writes later in thread: > On Thu, Jul 19, 2018 at 9:55 AM, Giampaolo Rodola' <g.rod...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/