
On 2 December 2017 at 00:16, Paul Moore <p.f.moore@gmail.com> wrote:
At the moment, 99% of the discussion seems rooted in generalised "it would help a lot of code" with readability arguments based on artificial examples, and that's not really helping move the discussion forward.
PEP 505 covers this in https://www.python.org/dev/peps/pep-0505/#motivating-examples (with an actual survey of standard library code, as well as some specific motivating examples from real world open source projects).
To be clear, I understand the problem of reading semi-structured data. I've hit it myself and been frustrated by it. But my reaction was "why am I not able to find a library that does this?", and when I couldn't find such a library, my assumption was that people in general don't find the current behaviour sufficiently frustrating to do anything about it. And I was in the same situation - it annoys me, but not enough to write a helper module (and certainly not enough that I'm crying out for a language change). So I do appreciate the need, I just don't think "language change" should be the first thing that's suggested.
The problem is that libraries don't have any way to manipulate attribute access chains in a usefully relevant way - you either have to put the control flow logic in line, or start writing helper functions like: def maybe_traverse_particular_subtree(obj): if obj is None: return None return obj.particular.subtree.of.interest And there are lots of other tricks used to make such code reasonably readable, with one of the most common being "Use a short placeholder variable name", so you get code like: fs = site.first_seen first_seen = fs if fs is None else fs.isodate() (from one of the proposed refactorings of the SiteView example in the PEP) Another variant on the "?? as pronoun" idea would be to use it as a new syntax for defining single argument lambda expressions: def call_if_not_none(lhs, deferred_rhs): return lhs if lhs is not None else deferred_rhs(lhs) first_seen = call_if_not_none(site.first_seen, (??.isodate()) However, I think that would actually be less clear and more confusing than the inline implicit pronoun idea. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia