[Python-ideas] Fwd: Null coalescing operator

[David Mertz]

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" <guido at 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 <mertz at 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" <python at 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 <guido at python.org
> >>> <mailto:guido at 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 at python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160910/540dccfc/attachment.html>