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

Andre Roberge andre.roberge at gmail.com
Mon Jul 23 10:03:24 EDT 2018


On Mon, Jul 23, 2018 at 6:52 AM Steve Dower <steve.dower at python.org> wrote:

> Responding to a few more ideas that have come up here.
>


​Thank you for the clarifications.​

​I'm trying to wrap my head around the various facets of None aware
operators proposal after reading the whole discussion - as well as having
read the PEP a few times.  Below is a
summary of what I gathered from the discussion, with a few added other
points that I have not seen addressed.

1. It is an operator present in other languages (e.g. C#, Dart), that uses
the same notation

a) This demonstrates that such an operator has been found to be useful and
is
definitely worth considering.

b) The fact that it uses the same notation is a plus for people that know
these other languages but it does not mean that the notation is necessarily
the best choice for Python. To wit, Python does not use the combination of
? and
: for ternary operator; instead it reuses existing keywords.

c) Some people use languages (e.g. Ruby) that allow ? to be part of an
identifier,
which means that one could, in principle, write something like

a = b?.c

in Ruby with a completely different meaning than what it would mean in C#
or Dart,
or as proposed for Python.Thus, I don't think that that language X uses
this operator written this way is,
**on its own**, a valid justification for using the exact same syntax for
Python.

d) Dart is given as an example. Reading from the link mentioned in the PEP,
I was lead to https://www.dartlang.org/guides/language/language-tour#classes
where the only mention of ?. was the following:

===
// If p is non-null, set its y value to 4.
p?.y = 4;
===

However, PEP 505 mentions that something like the above would raise a
SyntaxError.
Given that Dart's operator has a different semantics than that proposed for
Python,
I do not think that mentioning Dart in this context without any qualifier
is a valid supportive justification for this proposal.

2. On the specific choices of ??, ??=, ?., ?[]

a) Trying to find what Csharp ?? means by doing a quick internet search is
not exactly
productive.  By comparison, if one were to use a new keyword (say ifnone
instead
of ??) or keywords, it would make it easier to find their meaning. The
problem with new
keywords is that they may introduce some backwards incompatibility.

b) Admitedly, there are very few remaining symbols in Python that can be
used for defining new operators. Introducing operators using ? does not
cause problems with existing code.

c) While using a new keyword for ?? and ??= might work, it is less clear,
at least to me, how this could extend to ?. and ?[]

d) ? and ?? are already used by IPython with a totally different meaning.
I almost never use IPython I have no idea what problems this might cause
for IPython users.

3. On some examples given

PEP 505 gives these examples from Request:

data = [] if data is None else data
files = [] if files is None else files
headers = {} if headers is None else headers
params = {} if params is None else params
hooks = {} if hooks is None else hooks

It then argues that this is undesirable and that it could have been written
instead
as

data = data if data is not None else []
files = files if files is not None else []
headers = headers if headers is not None else {}
params = params if params is not None else {}
hooks = hooks if hooks is not None else {}

which, as written in PEP 505, is deemed to be "more intuitive" - but longer.

Having looked at the code in the Request module, I would argue that it
could have been written instead as

if data is None: data = []
if files is None: files = []
if headers is None: headers = {}
if params is None: params = {}
if hooks is None: hooks = {}

which gives the same result and is shorter than the original - but
admittedly longer than
the proposed notation. I do not think that this specific example as
currently written
in PEP 505 gives a fair picture of what is currently possible with Python.

4) On comparisons with other "domain specific operators", like @ and
the bitwise operators.

I do not remember the exact words that were used in the discussions, but
I seem to recall people saying that operators like ??, ?., etc. are no
more "mysterious" than @ or the bitwise operators might be: users should
not be surprised to have to learn new operators.

Anyone that does numerical work knows that matrix multiplications do not
obey the same rules as multiplications of numbers. If you don't do numerical
work, you are almost certain not to encounter @ as an operator (but only
as a symbol for decorator), so there won't be any mystery to solve.
A similar situation exists for bitwise operators.
Having dedicated operators to represent special methods on these types of
objects makes the code easier to read for people working in these fields.
I also note that these operators have corresponding dunder methods.

By contrast, code like

if a is None:
   a = []

can occur in pretty much any type of program and is, arguably, already very
readable.
Saying that it could/should be written instead as

a ??= []

where ??= would be an operator without corresponding dunder method is not
the
same. Unless I am mistaken, it would be the first time that operators
are introduced in Python without having corresponding dunder methods.
If I am correct in this, I believe that the PEP should at the very least
address this situation and provide an explanation as to why new operators
should be introduced that break this non-written rule in Python.

= = =

**Personal biases**: I do admit that I prefer code written in indented
blocks
to show the logic, over trying to cram everything in as few lines as
possible.  (The only exception to this is for list comprehensions,
but this might be because I am very familiar with mathematical notation
used for sets.)

Thus, I would likely always prefer to write

    if a is None:
        a = []

over

    if a is None: a = []


but I do admit that, after the initial shock, I do find

    a ??= []

to be fairly readable.  One thing I do find helpful is that it is
possible (and desirable) to have spaces around the operator.
Still, if such an operator was introduced, I would prefer a new
keyword over the proposed symbols, to be consistent with choices made
when the ternary operator construct was introduced.

However, even after reading it over many times, I do find code using
?. and ?[] to be much harder to read then using the current notation.
Python is often described as executable pseudo-code, which I consider
one of its strengths, and I find these proposed operators to look like
anything but executable pseudo-code.

Unlike the recently approved new operator, :=, whose meaning can be
at least guessed based on the presence of "=", there is nothing
intuitive about the choices of operators built from ?. The fact that
they would not be easily found by doing an internet search (other
than specifically looking for "python operators") compared with a search
for keywords based operators (e.g. "python ifnone") is not desirable imo.​

​André Roberge​




> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180723/5f23e939/attachment-0001.html>


More information about the Python-ideas mailing list