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

Abe Dillon abedillon at gmail.com
Sat Jul 28 23:56:13 EDT 2018


>
> Python does not have memory locations.
>

CPython does, form the documentation on the `id` function:

*CPython implementation detail:* This is the address of the object in
> memory.


I'm not sure what performance implications there would be for adding a
__none_check__ or whatever method to None.

None *is* an actual object. It
> has attributes, it has standard behaviours, it fits in the same object
> model as everything else in Python does.


 Cool. Thanks for the info. I wasn't sure because it's considered un-kosher
(according to PyCharm) to use "if x == None:" instead of "if x is None".

This is utter nonsense on par with trying to claim that "x <= y"
> should be parsed as if it's a modified form of assignment since "x =
> y" would be assignment.


This is getting tedious. It's only comparable to '<=' if you disregard
every other point I've made.
Python is supposed to emphasize readability and learnability. To that end,
expressions should strive to resemble natural language.
Otherwise they should try to resemble common mathematical notation. Failing
that, they should try to resemble common programming idioms.
There's no easy way to do subscripts, so we use square brackets for
indexing. That's a reasonable and pragmatic compromise.
`<=` is a fine compromise too because there's no easy way to type the ≤
symbol on most keyboards and it's a perfectly familiar symbol from
grade-school math.
Sure, someone could confuse '<=' for an assignment operator, I suppose; but
there's enough going for '<=' that it's easy to justify its existence for
pragmatism's sake.
The same can not be said for '?.'. It's not even remotely close to the same
thing.

"?." doesn't resemble anything in natural language. It doesn't resemble
anything in common mathematics. It isn't a well established pattern in
programming that has decades of precedent (like square bracket indexing).
It's not hard to check for None with a ternary statement. Adding a '?'
operator that goes at the end of an expression could do the same thing more
elegantly and resemble natural language at the same time. For all of those
reasons: I'm against this proposal.

Do I really need to explain how two-character operators work?


Point taken, I'll watch my tone. Rhodri James, I'm sorry for that flippant
remark about order of operations. It was uncalled for.

On Sat, Jul 28, 2018 at 3:14 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Sun, Jul 29, 2018 at 6:07 AM, Abe Dillon <abedillon at gmail.com> wrote:
> > Yes, I thought of that and came to the same conclusion. It's my
> > understanding that None may not be an actual object, but a special memory
> > location. I'm not sure though and didn't look it up.
>
> Python does not have memory locations. None *is* an actual object. It
> has attributes, it has standard behaviours, it fits in the same object
> model as everything else in Python does.
>
> >> As you said, "?" is not an operator, so "a?.b" clearly can't break down
> >> into "a? .b".
> >
> >
> > The problem is that '.' IS a stand-alone operator, so it's natural to
> > visually parse `<expr>.b` as `<expr>  .b`, but adding '?.' causes double
> > takes, more mental load, general interruption of the flow of reading. It
> > also sets up the later discussion of other possible uses of the '?'
> symbol
> > that may or may not have more merit.
>
> This is utter nonsense on par with trying to claim that "x <= y"
> should be parsed as if it's a modified form of assignment since "x =
> y" would be assignment.
>
> Do I really need to explain how two-character operators work?
>
> ChrisA
> _______________________________________________
> 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/20180728/660d0844/attachment-0001.html>


More information about the Python-ideas mailing list