Alex Hall writes:
> `dct.get('foo')?.get(0)?.get('bar')`.
>
> I would quite like to have PEP 505, but I don't know how to revive it. And
> I'm not surprised that it's deferred, there's generally reluctance to add
> new syntax, especially symbols.
Bottom line: new use cases or modified semantics that are more
attractive to people who don't sympathize with the "in NOSQL objects
often aren't there" use case. Some handwavy discussion below.
Note that Nick Coghlan in the PEP 622 thread over on python-dev is
proposing a very different use for '?' which seems likely to conflict.
It wouldn't rule out syntax, but definitely would make it more
difficult to use '?' (though probably not syntactically impossible)
for this purpose.
> I haven't seen anyone in this thread suggesting any cost or
> downside of adding the method, just people asking if it would be
> useful. I feel like I answered that question pretty thoroughly,
> then the thread went quiet.
Unfortunately, the people whose answers you really want to hear don't
hang out here much any more. Steven d'A has remarkably comprehensive
knowledge, but he's not as good at channeling Guido on what isn't yet
as he is at explaining what is already. Not sure where Andrew Barnert
has got to recently, but put him and Steven together and you get the
best of both that's available here. Greg Ewing is another valuable
source, but his design instincts often are quite different from
Guido's. Lots of good ideas and discussion from these developers, but
add all that up and you don't get Guido or Barry or Nick. Not
necessarily *worse*, but different, and if you can't show that some
feature requires a horrible hack or inordinate amounts of
hard-to-get-right trickery, being different from Guido still connotes
being un-Pythonic, and that's hard to get around. (Don't let that
stop you from arguing with Guido -- among his other remarkable
characteristics, he's been known to change his mind and accept
features he long opposed. :-)
I don't suggest that you try to open up a thread on python-dev where
the folks who dropped the acid in the Kool-Aid do show up frequently.
All of the reasons you and others give for wanting this are well-
known, and they just didn't do it. Until you've got a powerful new
argument or different, more attractive semantics, you'll just get
shooed back here.
I can say that it's not just the high cost of a symbol that tabled
that PEP. Chained accesses like "dct['foo'][0]['bar'] are just
expressions, but among the old-timers there's a deep suspicion of the
"fluent" style of programming, chaining method calls by returning
self. This isn't the same thing, but "null coalescing" operators (I
prefer "null propagating" but "coalescing" seems to be the preferred
term among proponents) has something of the same flavor, albeit only
for None. It necessarily privileges None[1], guaranteeing ambiguity
of that value, especially in a context like parsing JSON, where JSON
null is typically translated to Python None.
There was also a concern that null coalescing encourages hard to
debug, unmaintainable programming. I don't think anybody provided
hard evidence on that count, but introducing an operator specifically
to *postpone* detection of exceptional conditions just doesn't sit
well with a lot of people. It confuses things that *should* be there
but aren't, with things that *might* be there but aren't, and with
None when it's actually there. Postponing error detection can be done
with 'try', but try doesn't confuse those things.[2] The principle of
"consenting adults" means that possibility of misuse won't kill an
otherwise good idea, but the question "isn't there a more Pythonic,
explicit semantics that doesn't allow errors to propagate?" is one way
to get an idea tabled.
Finally, once you compare null-coalescing operators with 'try', it's
clear that 'try' is far more powerful as well as sufficient for this
application, and it's just not clear that null-coalescing is
sufficiently special a special case to deserve syntax.
Don't @ me. That is, I don't have a horse in this race (except that
it would be syntax I personally am unlikely to ever use, and probably
won't even see very often). I'm just trying to summarize some of the
themes of the discussion FYI.
Footnotes:
[1] Addition of a special NULL object was proposed, IIRC, but I
forget why that was considered a bad idea.
[2] On the other hand, ':=' got in even though that is what '=' is
for. That's a precedent that PEP 505 didn't have, turning a statement
into an expression.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GGOKSHNRRKARMU3J654DFETCCFRNRLMN/
Code of Conduct: http://python.org/psf/codeofconduct/
