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

Rhodri James rhodri at kynesim.co.uk
Fri Jul 27 08:00:09 EDT 2018


On 26/07/18 22:28, Abe Dillon wrote:
> The readability issue isn't just a matter of a new set of symbols to learn.
> It isn't even that the symbols are used in a non-intuitive way (though that
> doesn't help).

We could argue about how intuitive or not these operators are, but they 
are used in other languages, so they clearly aren't completely unintuitive.

> It's not even that the question mark, unlike the dot, is
> very visually obtrusive (which also doesn't help).

Being visually obtrusive would help a great deal.  Unfortunately I don't 
think it is visually obtrusive in the ?. and ?[] operators.

> It also screws with the
> grammar in an unexpected way. I would be fine with something like:
> 
> def func(data=None):
>      data ?= []
>      ...
> 
> If there were some corresponding dunder method to implement that behavior,
> but it's not clear to me that such a thing is possible.

We could conceivably have a dunder method that None implemented as 
returning the other argument and object implemented as returning itself. 
  I'm not really convinced that it's worth it, though.

> If it isn't, that
> would make `?=` (or '??=' though I don't see the need for double '?'s)

Because it's the in-place version of "??", obviously.

> a
> special statement, a special case that someone who's familiar with how
> other in-place operators work, would be thrown for a loop.

Really?  Quick straw poll: how often do people care how in-place 
operators are implemented?

> The other use
> cases look like they break down in a different manner than they actually do:
> 
> person?.name
> 
> looks like it would break down similar to
> 
> person().name
> 
> but it doesn't because '?' by itself is not an operator.
> similarly:
> 
> person?[0]
> 
> looks like it would break down similar to
> 
> person()[0]
> 
> but again, the operator is '?[...]' not '?'

Sorry, not buying this one.  As you said, "?" is not an operator, so 
"a?.b" clearly can't break down into "a? .b".  This all rather feels 
like you are trying to find justifications for not liking these 
operators rather just saying "I don't like them," and frankly I'd 
respect you more if you just said "I don't like them."

(For the record, I don't like most of them.  There are clear use cases 
for "??" and "??=", but the use cases I've seen for "?." and "?[]" 
aren't convincing to me.)

> This also raises the question of other operators that could be made null
> aware. Why not:
> 
> func?()
> 
> ?-num
> 
> ?~num
> 
> num ?+ other
> 
> Why not other reflective operators?
> 
> num ?+= other

Why not indeed.  I haven't seen any convincing use cases (and nor has 
the PEP, though I doubt Steve was looking for them), but they aren't 
inherently any more weird than "?." and "?[]".

> I think this could be helped by simply making '?' an operator with a very
> high order of operations, so that pretty-much any expression on the LHS is
> guarded for 'NoneType' AttributeErrors:
> 
> val = person[0]?
> val = person.name?

Um.  How is that supposed to parse?  "person[0]" has already been 
evaluated by the time the "?" operator gets anywhere near it.  Unless 
you are proposing some major surgery to the parser (which I'm pretty 
sure isn't going to happen), this has no chance of getting through. 
Good thing too, because it's a lot more surprising than the alternatives.

> I also disagree with the idea that None is special enough to warrant such
> special behavior. There are other special None-like objects (as David Mertz
> pointed out) like NaN and custom place-holders for cases where None is a
> valid argument.

NaN isn't used like None, though, and custom sentinels aren't that common.

> Yet another possibility is to make '?' signify a parameter who's default
> value is an expression that should be evaluated when necessary:
> 
> def func(data: List = []?):
>      ...
> 
> That gets closer to another often requested feature: delayed expression
> evaluation (as Steve D'Aprano pointed out).
> So there are other, possibly better uses for the '?' symbol. It's something
> that needs to be carefully considered.

While my immediate reaction is "yuk", your use of "?" does not conflict 
with any use in the PEP, so this is a red herring.

-- 
Rhodri James *-* Kynesim Ltd


More information about the Python-ideas mailing list