I actually think that Zero's point here is quite valid... At some earlier point in the thread, I believe that Nick Coughlin was saying that we should be asking ourselves _why_ we want to do something like this and the result of that discussion was because there is pain when working with "pseudo-structured" responses from various APIs. This use-case resonates with me as I work with JSON responses quite frequently.

The thing about "pseudo-structured" data is that there isn't an agreed upon way to represent it. While one API might send a field with a `null` value in some cases, another API might send a field with no data (after all, why bother putting it in the response if it's going to be `null`? You're just wasting bytes on the wire). As a concrete case where fields are truly missing -- Most of the Google APIs accept a "fields" parameter that allows you to pair down what is actually included in the response (If you don't believe me, feel free to play around with it in their API explorer -- https://developers.google.com/google-apps/calendar/v3/reference/calendars/get).

So, while this proposal is specifically about a "Null coalescing operator", my guess is that users will think of it as a "Get the field if it exists, else short-circuit and return `None`". And it might take a lot of education to try to get everyone aligned on the same page around what the "if it exists" actually means. At first, I was thinking that perhaps _adding_ an operator would help the community to standardize around "If the field is missing, then put a `None` in there -- But unfortunately, I think that the JSON API example demonstrates that a really big use-case for this operator is in working with APIs that are likely written in different languages whose communities frequently don't follow the same norms that python has embraced.

I suppose that the suggestion would be to write:

foo.get('bar')?['baz']

if the `foo` dict may or may not have ` bar` key?

On Wed, Nov 2, 2016 at 3:22 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

Zero Piraeus writes:

If I write something like obj.attr, the failure mode I care about is
that
obj has no attribute attr, rather than that obj is specifically None (or
one of a defined group of somewhat Nonelike objects).

Clearly, in such a circumstance, obj is not what I expected it to be,
because I thought it was going to have an attribute attr, and it
doesn't.

If it's an error, you shouldn't be trying to do anything
about it, just let the exception happen.

The proposed .? syntax is designed for cases where it's *not*
an error for the object to be missing the attribute, *and*
the correct action in that situation is to skip whatever
you would have done otherwise.

What needs to be decided is whether such use cases are frequent
enough to justify special syntax.

--
Greg

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Matt Gilson // SOFTWARE ENGINEER

E: matt@getpattern.com // P: 603.892.7736

We’re looking for beta testers. Go here to sign up!