I'm perfectly fine with defining get and get_in ala Clojure and using them (they work on __getitem__ supporting things, so dicts, lists, strings, most random user-level containers). I go a bit further in my codebases and implement:
def get(obj, k, default=None):
""" safe __getitem__ obj[k] with a default """
def assoc(obj, k, v):
""" obj[k] = v returning obj """
def dissoc(obj, k):
""" safe del obj[k] returning obj without k"""
def get_in(obj, keys, default=None):
""" __getitem__ obj[k0][k1][kn] with a default. """
def assoc_in(obj, keys, v, default=lambda n: dict()):
""" __setitem__ obj[k0][k1][kn] = v. __getitem__ failures handled with default """
def dissoc_in(obj, keys):
""" Return obj asserting that obj[k0][k1][kn] does not exist. """
def update_in(obj, keys, update_fn=None, default=lambda n:dict()):
""" Update the value at obj[k0][k1][kn] with update_fn returning obj. __getitem__ failures handled by default. """
def merge_with(fn, **dictionaries):
""" Merge resolving node conflicts with fn """
def deep_merge_with(fn, **dictionaries):
""" Recursively merge resolving node conflicts with fn"""
as a matter of course in most of python webapp and data munging projects. They are insanely useful when working with the gobs of JSON that is common when interacting with modern web services. I really should throw the implementations into a public library at this point.
> Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None.
Producing NULL (or whatever the languages equivalent is) isn't an error -- if there was an error, it would be throwing an exception, not returning NULL. The idea of "do this chain of operations propagating nulls encountered at any point" is reasonably useful.
I just hate NULL standing in for a boolean notion of existence, I'd rather see a separate boolean member indicating the validity of the other member (string middle_name; boolean has_middle_name;). Or in a strongly typed language an Option/Maybe type. Just assigning things NULL sometimes has the problem of people looking at the object and assuming everything will always be populated.
> But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.
