On Fri, Jul 3, 2020 at 5:36 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> 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 -- 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/AOVJ2SZ4G3O4NJYAOBRX2T6SCH2I5JZI/ Code of Conduct: http://python.org/psf/codeofconduct/