On Fri, Jul 3, 2020 at 5:36 AM Stephen J. Turnbull <
[email protected]> wrote:
> 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.
>
> 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.
>
Thanks Stephen, it's nice to get some idea of what happened to PEP 505. It
would be great if someone could put an official summary in the PEP, like a
"Deferral notice".
However it feels like you misread my email. You quote me saying this:
> 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.
but then apparently go on to talk about PEP 505. At that point I was
talking about the low cost of a `list.get` method, in contrast to PEP 505.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/AOVJ2SZ4G3O4NJYAOBRX2T6SCH2I5JZI/
Code of Conduct: http://python.org/psf/codeofconduct/
