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. Objects should be valid.

Not happening, because it would mean multi-line function arguments, which have been declared "ugly".

http://legacy.python.org/dev/peps/pep-3099/

Guido explains in an old blog post (http://www.artima.com/weblogs/viewpost.jsp?thread=147358) that he considers all of the possible implementations of multi-line lambdas to be un-Pythonic:

> 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.

Wouldn't you just define a function in that case? Guido has mentioned[1] that he isn't a fan of lambda functions.

[1] http://www.linuxjournal.com/article/2959