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.ew...@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/ > -- [image: pattern-sig.png] Matt Gilson // SOFTWARE ENGINEER E: m...@getpattern.com // P: 603.892.7736 We’re looking for beta testers. Go here <https://www.getpattern.com/meetpattern> to sign up!
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
