For kicks I looked at the code in a commercial product that we are open sourcing very soon at Continuum Analytics. It has about 27k lines of Python and Cython. I checked it just by running `grep -C3 'if.*None'` over the source code and eyeballing.
Obviously, this code might be refactored if other syntax was available. And I personally wrote only a small part of the code, so I might write it differently either way. But looking through, the uses of 'is (not) None' I found fell into a few categories. Some were suites of statements under the 'foo is None' branch. Those would have to remain suites. Some are single line returns, other single line raise. Those I call 'value' are the ones that would lend themselves to the 'bar = foo ?? baz' style. The ones I call 'attribute' are the cases where we test for non-None before accessing an attribute of the object. The thing that I found surprisingly common was cases where a compound condition was used, e.g. 'if x is None and y > 37'. Those might be possible to refactor, but cannot be directly rewritten in the coalescing style. - Suite: 75 - Return: 21 - Raise: 13 - Value: 46 - Attribute: 2 - Compound condition: 25 On Sat, Sep 10, 2016 at 7:15 PM, David Mertz <me...@gnosis.cx> wrote: > How much of the time is a branch of the None check a single fallback value > or attribute access versus how often a suite of statements within the > not-None branch? > > I definitely check for None very often also. I'm curious what the > breakdown is in code I work with. > > On Sep 10, 2016 7:10 PM, "Guido van Rossum" <gu...@python.org> wrote: > >> To the contrary. I read and write code that performs explicit checks >> for None all the time. Catching AttributeError is often a code smell >> or at least a measure of last resort. >> >> On Sat, Sep 10, 2016 at 6:46 PM, David Mertz <me...@gnosis.cx> wrote: >> > Ok, I have been thinking of the behavior too broadly. I realize now that >> > `x?.foo` might still simply raise an AttributeError if x is neither >> None nor >> > a thing with a foo attribute. >> > >> > The class I wrote is definitely too aggressive for the behavior >> described. >> > On the other hand, by being narrower in behavior there feels like even >> less >> > motivation for new syntax. >> > >> > >> > On Sep 10, 2016 6:29 PM, "MRAB" <pyt...@mrabarnett.plus.com> wrote: >> >> >> >> On 2016-09-11 02:02, David Mertz wrote: >> >>> >> >>> On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum <gu...@python.org >> >>> <mailto:gu...@python.org>> wrote: >> >>> >> >>> No. PEP 505 actually solves the problem without ever catching >> >>> AttributeError. Please read it. >> >>> >> >>> >> >>> I read it again (I did a year ago, but reviewed it now). I hadn't >> been >> >>> thinking that the *mechanism* of a new None-coalescing operator would >> >>> actually be catching an exception. It could (and should) work >> >>> differently if it becomes syntax. >> >>> >> >>> What I was getting at with "essentially" was that it would *do the >> same >> >>> thing* that an AttributeError does. That is, if `x.foo` can't be >> >>> evaluated (i.e. x doesn't have an attribute 'foo'), then access is >> >>> informally "an error." The hypothetical "x?.foo" catches that "error" >> >>> and substitutes a different value. The particular implementation >> >>> under-the-hood is less important for most programmers who might use >> the >> >>> construct (and I think documentation would actually give an informal >> >>> equivalent as something similar to what I put in the NoneCoalesce >> class). >> >>> >> >> x?.foo would lookup attribute 'foo' _unless_ x was None, in which case >> it >> >> would return None. It's simply: >> >> >> >> None if x is None else x.foo >> >> >> >> This means that None?.__str__() would return None, not 'None'. (None >> has >> >> an attribute called '__str__', and None.__str__() returns 'None', but >> it >> >> would not be looked up because None is, well, None.) >> >> >> >> _______________________________________________ >> >> Python-ideas mailing list >> >> Python-ideas@python.org >> >> https://mail.python.org/mailman/listinfo/python-ideas >> >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > >> > >> > _______________________________________________ >> > Python-ideas mailing list >> > Python-ideas@python.org >> > https://mail.python.org/mailman/listinfo/python-ideas >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
