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

[Steven D'Aprano]

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.

In context, the argument was that non-word symbols are not always worse 
than words, not that all symbols are "the same".

Obviously symbols that we use regularly will be more familiar and easier 
to recognise than symbols we use rarely. I still have to make a 
conscious action to recall which of ∩ and ∪ is set union and 
intersection, and don't ask me what set symmetric difference is. And 
even after 20 years of Python I still occasionally write ^ for 
exponentiation instead of **.

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.


> They clearly are not. Anybody learned those symbols at elementary 
> schools, all programming languages have them and using math in 
> programming is common enough to justify a symbol over a keyword. "a + 
> b" is literally just an addition and nothing else.

That's not quite correct: '+' in Python is used for both addition and 
sequence concatenation. And with operator overloading, it can be 
anything at all. But it is *usually* addition, or concatenation.

I don't know what it is like in your country, but here in Australia, I 
don't know any school that teaches * for multiplication except in 
programming classes, which is not a core subject. The usual symbol we 
have for multiplication is × and sometimes ⋅ (dot operator).

This is a good point: after learning * for multiplication, it becomes so 
familiar that most of us forget that we haven't been using it forever. 
It becomes second-nature. In the same way that @ for decorators has 
become second nature, or slice notation. Both of which are terribly 
mysterious to people just starting out.

We shouldn't judge proposals on how mysterious they are the first time 
we see them, because everything is mysterious the first time. We should 
try to look forward to when we've seen them ten or twenty times. How 
will the "usefulness versus surprise" trade-off appear when, let's say, 
50% of the surprise has been worn away with experience?

As a community, we're risk-adverse. I understand why we should be 
conservative in what we add to the language (once added, it cannot 
easily be removed if it turns out to be a mistake) but on Python-Ideas 
we regularly demand levels of obviousness and "readability" that 
existing syntax does not reach.

(For example, the dot operator for attribute access fails the "syntax 
should not look like grit on Tim's monitor" test.)

I believe that it is fine to prefer that new syntax is no harder to 
learn or use than (for example) // or ** (neither of which is taught in 
maths class), or slice notation. But I don't think it is fair, or 
desirable, to demand levels of readability greater than what we already 
have in the less common corners of the language.

All the obvious operators are already in use. Anything we add now is 
going to be a little bit niche, a little bit unusual. It's not like 
we're going to suddenly realise we forgot to include a "subtract" 
operator. So it is perfectly natural that any new operators won't be as 
familiar as + or - operators. But it might become as familiar as ** or 
<< operators, or some of the less common regex patterns, and that's 
okay. Not everything needs to be as recognisable as the plus sign.


> The "?" variants have multiple meanings, spellings and implications:
[...]

Indeed. And I think we ought to think carefully about the benefits and 
costs of all of those variants separately.

To me, the ?? operator seems like a clear and obvious win. The other 
variants are more complex and the benefit is not as obvious to me, so I 
haven't decided where I stand on them.


-- 
Steve