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

Giampaolo Rodola' g.rodola at gmail.com
Tue Jul 24 06:38:19 EDT 2018


On Tue, Jul 24, 2018 at 11:50 AM Steven D'Aprano <steve at pearwood.info> wrote:
>
> On Tue, Jul 24, 2018 at 12:05:14AM +0200, Giampaolo Rodola' wrote:
>
> > This:
> >
> >     v = a?.b
> >
> > ...*implicitly* checks if value is not None [and continues execution].
>
> Do you agree that:
>
>     obj.attribute
>     x + 1
>     func(arg)
>
> explicitly looks up an attribute on obj, explicitly adds 1 to x, and
> explicitly calls func with a single argument? I don't think that we have
> to write COBOL-esque code to be explicit:
>
>     GET ATTRIBUTE "attribute" FROM obj
>     ADD 1 TO x
>     CALL FUNCTION func WITH ARGUMENT arg
>
> I don't accept that the use of punctuation makes something implicit. But
> if you want to argue that anything with punctuation is "implicit", then
> okay, Python has lots of implicit punctuation.
> By definition, ?. checks for None before doing the attribute lookup.
> That is completely explicit, regardless of how it is spelled:
>
>     obj?.attribute

You totally missed my point about explicitness. Nevermind.

> > This
> >
> >     v = a
> >     if a.b is not None:
> >         v = a.b
> >
> > ...*explicitly* checks if value is not None and continues execution.
>
> If you are trying to match the behaviour of a?.b above, it is also
> completely buggy and doesn't do what is intended.
>
>     # Equivalent of a?.b
>     v = a
>     if v is not None:
>         v = v.b
>
>
> > If for some reason '?'[ is also going to swallow LookupError
>
> What makes you think that ?[...] will swallow LookupError?
>
> Please don't argue against misfeatures that the PEP doesn't propose.
> Nothing in PEP 505 swallows any exceptions. Swallowing exceptions is
> explicitly rejected, and swallowing LookupError isn't part of the
> proposal.

I know it's not in the PEP. I merely mentioned that as PEP author was
questioning that possibility in previous messages. It was an example
(for you) on how *that* would make things even less explicit.

> [...]
> > One may argue that silently returning None instead of raising
> > AttributeError is also less explicit.
>
> And again, you are arguing against a misfeature which PEP 505 does not
> propose. The ?. operator will not suppress AttributeErrors.
>
>     # Wrong! No! This is not what the PEP proposes!
>     obj = 1.234
>     assert obj?.hexx is None

That is not what I meant at all!
I seriously question whether you really don't understand or you're
just pretending.
What I meat in here was 'a?.b?.c?' returning None in case 'b' is None.

> [...]
> > > It isn't a first. Many existing operators use two adjacent symbols not
> > > interrupted by a space:
> > >
> > > e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.
> >
> > You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> > would be less intuitive anyway). You can't because '.?' is the only
> > couple of contiguous symbols requiring "something" before and after
> > with no spaces in between, and that's a first in the language.
>
> Why do you think spaces aren't allowed? The PEP explicitly says that
> the new operators can be used wherever the regular operators can be
> used.
> [...]
> That tells me that ?. will be legal anywhere . is legal, so if x . y is
> legal (and it is) so will x ?. y be legal.

Yes, I forgot 'a . b' was legal - my bad.

> [...]
> > The difference is that 'a.b.c.d' will result in AttributeError as soon
> > as something is None while 'a?.b?.c?.d' will return None instead.
>
> Correct. Because sometimes you want an AttributeError, and sometimes you
> want None.
>
> You are criticising the operator for doing what it is designed and
> intended to do. You might as well criticise getattr(obj, 'spam', None)
> for returning None.
>
> If you want an AttributeError, then don't use ?. and use ordinary .
> instead.

Again, you missed my point.

> > > Likewise the logical operators "or" and "and" are designed to
> > > short-circuit. If ?? and friends are a mistake because they
> > > short-circuit, why aren't "or" and "and" mistakes?
> > > I'm not asking this as a rhetorical question. If you think there is a
> > > reason why it is okay for or/and to short-circuit, but it is bad for ??
> > > and friends to short-circuit, then please explain why they are
> > > different. I will be very happy to listen to your arguments.
> >
> > The argument about this is that '?.' short-circuits execution
> > *silently*.
>
> Other short-circuit operators also short-circuit execution silently.
> That's what they are designed to do.
>
>     # This isn't what actually happens.
>     py> x = 0
>     py> result = x and 1/x
>     __main__:1: UserWarning:
>     Short-cut operation occurred, the right hand operand was not
>     evaluated!!! Do not panic, this is the expected behaviour!!!
>     py> print(result)
>     0
>
>
> > Instead of AttributeError you get None. You may chain ?.
> > in order to lazily traverse a long tree,
>
> Correct, that is what it is designed to do.
>
>
> > inadvertently assign None to
> > a variable, continue code execution and fail later rather than sooner:
> >
> >      email = request?.context?.user?.email  # None
> >      ...
> >      sendmail(subject, body, email)
> >
> > Some (Antoine) rightly argued this may even have security implications
> > (replace 'email' with 'password').
>
> I'll have to remember that. Whenever there's any proposal for a feature
> I don't like, just claim it "may even have security implications". Who
> needs evidence when we have Fear, Uncertainty, Doubt?

OK, I'm done replying to you. I just wish I did it earlier (my bad).

--
Giampaolo - http://grodola.blogspot.com


More information about the Python-ideas mailing list