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

[Ivan Levkivskyi]

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.0x2a at 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 <rosuav at gmail.com> wrote:
>
>> On Fri, Jul 20, 2018 at 10:03 AM, Greg Ewing
>> <greg.ewing at 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 at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> _______________________________________________
> 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/20180721/385673b0/attachment.html>