I think I am with Michael here. I like the parallel between `??` and `or`, we don't have `or=`, so `??=` is also not needed.
Although I understand a parallel between `obj.attr` and `obj['attr']`, I think there is an additional point (in addition to two valid points by Michael) why I don't like `?[`: in many situations in my experience optional container attributes were results of suboptimal APIs, so I would not encourage this pattern. FWIW, I am rather -0 on adding all proposed operators, but I would be +1 on adding just the two essential ones: ?? and ?. -- Ivan On 20 July 2018 at 01:40, Michael Lee <michael.lee.0...@gmail.com> wrote: > Hi -- I'm a new voice here, though I've been lurking for a while now. > > How do people feel about removing "??=" and "foo?[bar]" from the PEP and > sticking with just "foo?.bar" and "foo ?? bar"? > > Reasons for not implementing "??=": > > 1. I think the other operators are useful in that they can be chained > together to shrink many different lines of code. In contrast, ??= can > shrink at most one line of code: we get to remove a single 'if foo is > None'. If the rest of the PEP is implemented, we can also just express > this by doing "foo = foo ?? some_expr" which I think is still > relatively concise. > > 2. None of the other short-circuiting operators have an augmented > assignment form -- e.g. we can do "foo = foo or bar", but there's no > such thing as "foo or= bar". I don't really see why ?? in particular > deserves to have an augmented assignment form. > > 3. We already have two different kinds of assignment operators with > the inclusion of PEP 572 -- in the interests of keeping Python as simple as > possible, I think it'd be a good idea not to add a third one. > > > Reasons for not implementing "foo?[bar]": > > 1. It seems like "foo?[bar]" could be easily confused with "foo??[bar]". > I don't think it's immediately obvious to a newcomer which spelling > corresponds to which usage, and getting the two mixed up seems like the > sort of thing that could cause all sorts of subtle bugs. > > 2. We can already easily get the same functionality using standard > Python. E.g., instead of doing foo?["bar"]?[0]?["baz"], we could do > lookup(foo, > "bar", 0, "baz") where lookup is a function that looks roughly like > this: > > def lookup(item, *parts): > for part in parts: > if item is None: > return None > item = item[parts] > return item > > Of course, we could probably create the same sort of function to > replace foo?.bar (albeit less ergonomically), but unlike foo?[bar], > there's no possibility for confusion: doing foo??.bar will never be a > valid Python expression. > > 3. One counter-argument against removing foo?[bar] is that it would > make expression that need both safe index and attribute lookups look weird > -- you'd sometimes be using the "lookup" function described above (or > something similar) and sometimes using ".?". However, I'd argue that these > sorts of scenarios are relatively rare in practice, and that if you really > need to deal with a bunch of code that requires you to use both forms of > safe navigation, your code is likely already becoming pretty unreadable and > should be rewritten -- maybe split up into multiple lines or something, or > maybe just redesigned from scratch so you don't need to constantly manage a > mess of Nones. > > > More broadly, I think I agree with the sentiment some other people have > that Python has acquired a lot of new features in a relatively short period > of time, and that it would be nice to have some cooldown to let tooling and > other implementations catch up. In that regard, I'd personally be happy if > we didn't implement this PEP or just deferred it again. But if we *are* > moving forward with it, I think it's worth trying to simplify it as much as > possible/try and make it orthogonal with existing Python features. > > (But of course, I'm just some random person on the internet, so IDK if my > opinion counts for much.) > > Regards, > -- Michael > > > On Thu, Jul 19, 2018 at 5:06 PM, Chris Angelico <ros...@gmail.com> wrote: > >> On Fri, Jul 20, 2018 at 10:03 AM, Greg Ewing >> <greg.ew...@canterbury.ac.nz> wrote: >> > Rhodri James wrote: >> >> >> >> If anyone can think of a good word for "if it isn't None, otherwise", >> I'd >> >> be all for it :-) >> > >> > >> > I don't think there's any single Engish word that captures >> > all of that, so we'd have to invent one. >> > >> > Some suggestions: >> > >> > inno (If Not None, Otherwise) >> > >> > oft (Or, Failing That) >> >> Iunno, that'd oft be confusing. >> >> Kappa >> >> ChrisA >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/