[Python-ideas] PEP 505: None-aware operators

Steven D'Aprano steve at pearwood.info
Tue Jul 31 15:50:06 EDT 2018


On Tue, Jul 31, 2018 at 02:14:19PM -0400, David Mertz wrote:
> On Tue, Jul 31, 2018, 1:47 PM Steven D'Aprano <steve at pearwood.info> wrote:
> 
> > Yes it is. Rhodri is correct, although I admit that I hadn't realised
> > this point myself until he pointed it out. (That is why until now I've
> > been writing examples like "spam?.eggs?.cheese?.aardvark" which is
> > redundant.)
> >
> 
> Again, one of the most vocal advocates of the PEP gets the semantics wrong!
> 
> `spam?.eggs?.cheese?.aardvark` is NOT redundant for `
> spam?.eggs.cheese.aardvark`.

It is if *only* spam can be None, which is the scenario being discussed.

Please don't ignore the context of statements. I didn't say that

    spam?.eggs.cheese.aardvark

would guard against eggs or cheese being None. That interpretation of my 
comment is uncharitable and not supported by my re-write of the 
pseudo-code from the PEP.

It also goes completely against my comment "Figuratively speaking..." 
that the ?. operator groups to the right:

    spam?(.eggs.cheese.aardvark)  # grouping, not function call.

Perhaps you didn't read my post all the way to the end before firing off 
a triumphant post accusing me of getting it wrong.

In context, the question is whether:

    spam?.eggs.cheese.aardvark

might attempt to evaluate None.cheese.aardvark. It won't.

In context, the issue was not whether these two expressions are 
identical in every imaginable way:

    spam?.eggs.cheese.aardvark

    spam?.eggs?.cheese?.aardvark

In pseudo-code, they would be something close to:

    if spam is not None:
        return spam.eggs.cheese.aardvark

versus

    if spam is not None:
        if spam.eggs is not None:
            if spam.eggs.cheese is not None:
                return spam.eggs.cheese.aardvark

except without needing to evaluate each subexpression multiple times.

In context, we are discussing the behaviour when spam is None. When spam 
is None, there's no need for the additional maybe-dots, because the 
first short-circuits the rest. If additional attributes also could be 
None, then they too could be guarded with maybe-dot operators, but if 
they are never None, it is unnecessary and redundant to guard spam alone 
all the way through the expression with maybe-dots.


> The two expressions simply do different
> things, but in a way guaranteed to assure that also everyone gets the
> actual behaviors wrong.

Putting aside your prejudicial language about guaranteeing errors, I 
think that the PEP could be improved. I managed to read it multiple 
times without taking in the fact that ?. short-circuits to the right. I 
didn't explicitly say so (perhaps I should have) but I too initially 
made the same error as Abe, assuming that

    spam?.eggs.cheese

would fail if spam was None (evaluating None.cheese) but according to 
the PEP that's not the case.

With a working implementation, it would be the work of moments for
people to experiment in the REPL and clarify any lingering doubts about 
the operation.

Without it, there will always be some misunderstandings from those who 
(like me) failed to read the documentation carefully enough and made 
upjustified assumptions. That's no different from any other non-trivial 
feature.


-- 
Steve


More information about the Python-ideas mailing list