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

Chris Angelico rosuav at gmail.com
Sun Jul 22 16:01:14 EDT 2018


On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
> On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico <rosuav at gmail.com> wrote:
>>
>> On Sun, Jul 22, 2018 at 11:35 PM, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
>> > On Sun, Jul 22, 2018 at 2:10 PM Steven D'Aprano <steve at pearwood.info> wrote:
>> >>
>> >> On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
>> >> > On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano <steve at pearwood.info> wrote:
>> >> [...]
>> >> > > I don't think that "+" is harder to read than
>> >> > > "standard_mathematics_operators_numeric_addition"
>> >> >
>> >> >
>> >> > Please let's drop the argument that + - * / = and ? are the same.
>> >> [...]
>> >> But if we insist that every symbol we use is instantly recognisable and
>> >> intuitively obvious to every programmer, we're putting the bar for
>> >> acceptance impossibly high.
>> >
>> > I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
>> > but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
>> > Perl-ish to me, non pythonic and overall not explicit, no matter what
>> > the chosen symbol is gonna be.
>>
>> Please explain what is not explicit about it. "a?.b" is very simple
>> and perfectly explicit: it means "None if a is None else a.b". What
>> does "not explicit" mean, other than "I don't like this code"?
>
> I find it less explicit mainly because it does 3 things at once: check
> if attribute is None, use it if it's not None and continue the
> evaluation from left to right. I find that logic to be more explicit
> when living on different lines or is clearly delimited by keywords and
> spaces. ? has no spaces, it's literally "variable names interrupted by
> question marks" and evaluation can stop at any time while scanning the
> line from left to right. Multiple "?" can live on the same line so
> that's incentive to write one-liners, really, and to me one-liners are
> always less explicit than the same logic split on multiple lines.

Ah, I see what you mean. Well, think about what actually happens when
you write "lst.sort()". In terms of "hidden behaviour", there is far
FAR more of it in existing syntax than in the new proposals. Which is
back to what Steven said: people demand such a high bar for new syntax
that few existing pieces of syntax would pass it.

ChrisA


More information about the Python-ideas mailing list