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:
if the `foo` dict may or may not have ` bar` key?