How to make a python dictionary that returns key for keys missing from the dictionary instead of raising KeyError?

I want to create a python dictionary that returns me the key value for the keys are missing from the dictionary.

Usage example:

dic = smart_dict()
dic['a'] = 'one a'
# >>> one a
# >>> b


dicts have a __missing__ hook for this:

class smart_dict(dict):
    def __missing__(self, key):
        return key

Why don't you just use

dic.get('b', 'b')

Sure, you can subclass dict as others point out, but I find it handy to remind myself every once in a while that get can have a default value!

If you want to have a go at the defaultdict, try this:

dic = defaultdict()
dic.__missing__ = lambda key: key
dic['b'] # should set dic['b'] to 'b' and return 'b'

except... well: AttributeError: ^collections.defaultdict^object attribute '__missing__' is read-only, so you will have to subclass:

from collections import defaultdict
class KeyDict(defaultdict):
    def __missing__(self, key):
        return key

d = KeyDict()
print d['b'] #prints 'b'
print d.keys() #prints []

The first respondent mentioned defaultdict, but you can define __missing__ for any subclass of dict:

>>> class Dict(dict):
        def __missing__(self, key):
            return key

>>> d = Dict(a=1, b=2)
>>> d['a']
>>> d['z']

Also, I like the second respondent's approach:

>>> d = dict(a=1, b=2)
>>> d.get('z', 'z')

Congratulations. You too have discovered the uselessness of the standard collections.defaultdict type. If that execrable midden heap of code smell offends your delicate sensibilities as much as it did mine, this is your lucky StackOverflow day.

Thanks to the forbidden wonder of the 3-parameter variant of the type() builtin, crafting a non-useless default dictionary type is both fun and profitable.

What's Wrong with dict.__missing__()?

Absolutely nothing, assuming you like excess boilerplate and the shocking silliness of collections.defaultdict – which should behave as expected but really doesn't. To be fair, Jochen Ritzel's accepted solution of subclassing dict and implementing the optional __missing__() method is a fantastic workaround for small-scale use cases only requiring a single default dictionary.

But boilerplate of this sort scales poorly. If you find yourself instantiating multiple default dictionaries, each with their own slightly different logic for generating missing key-value pairs, an industrial-strength alternative automating boilerplate is warranted.

Or at least nice. Because why not fix what's broken?

Introducing DefaultDict

In less than ten lines of pure Python (excluding docstrings, comments, and whitespace), we now define a DefaultDict type initialized with a user-defined callable generating default values for missing keys. Whereas the callable passed to the standard collections.defaultdict type uselessly accepts no parameters, the callable passed to our DefaultDict type usefully accepts the following two parameters:

  1. The current instance of this dictionary.
  2. The current missing key to generate a default value for.

Given this type, solving sorin's question reduces to a single line of Python:

>>> dic = DefaultDict(lambda self, missing_key: missing_key)
>>> dic['a'] = 'one a'
>>> print(dic['a'])
one a
>>> print(dic['b'])

Sanity. At last.

Code or It Didn't Happen
def DefaultDict(keygen):
    Sane **default dictionary** (i.e., dictionary implicitly mapping a missing
    key to the value returned by a caller-defined callable passed both this
    dictionary and that key).

    The standard :class:`collections.defaultdict` class is sadly insane,
    requiring the caller-defined callable accept *no* arguments. This
    non-standard alternative requires this callable accept two arguments:

    #. The current instance of this dictionary.
    #. The current missing key to generate a default value for.

    keygen : CallableTypes
        Callable (e.g., function, lambda, method) called to generate the default
        value for a "missing" (i.e., undefined) key on the first attempt to
        access that key, passed first this dictionary and then this key and
        returning this value. This callable should have a signature resembling:
        ``def keygen(self: DefaultDict, missing_key: object) -> object``.
        Equivalently, this callable should have the exact same signature as that
        of the optional :meth:`dict.__missing__` method.

        Empty default dictionary creating missing keys via this callable.

    # Global variable modified below.
    global _DEFAULT_DICT_ID

    # Unique classname suffixed by this identifier.
    default_dict_class_name = 'DefaultDict' + str(_DEFAULT_DICT_ID)

    # Increment this identifier to preserve uniqueness.

    # Dynamically generated default dictionary class specific to this callable.
    default_dict_class = type(
        default_dict_class_name, (dict,), {'__missing__': keygen,})

    # Instantiate and return the first and only instance of this class.
    return default_dict_class()

Unique arbitrary identifier with which to uniquify the classname of the next
:func:`DefaultDict`-derived type.

The key ...get it, key? to this arcane wizardry is the call to the 3-parameter variant of the type() builtin:

type(default_dict_class_name, (dict,), {'__missing__': keygen,})

This single line dynamically generates a new dict subclass aliasing the optional __missing__ method to the caller-defined callable. Note the distinct lack of boilerplate, reducing DefaultDict usage to a single line of Python.

Automation for the egregious win.

I agree this should be easy to do, and also easy to set up with different defaults or functions that transform a missing value somehow.

Inspired by Cecil Curry's answer, I asked myself: why not have the default-generator (either a constant or a callable) as a member of the class, instead of generating different classes all the time? Let me demonstrate:

# default behaviour: return missing keys unchanged
dic = FlexDict()
dic['a'] = 'one a'
# 'one a'
# 'b'

# regardless of default: easy initialisation with existing dictionary
existing_dic = {'a' : 'one a'}
dic = FlexDict(existing_dic)
# 'one a'
# 'b'

# using constant as default for missing values
dic = FlexDict(existing_dic, default = 10)
# 'one a'
# 10

# use callable as default for missing values
dic = FlexDict(existing_dic, default = lambda missing_key: missing_key * 2)
# 'one a'
# 'bb'
# 4

How does it work? Not so difficult:

class FlexDict(dict):
    '''Subclass of dictionary which returns a default for missing keys.
    This default can either be a constant, or a callable accepting the missing key.
    If "default" is not given (or None), each missing key will be returned unchanged.'''
    def __init__(self, content = None, default = None):
        if content is None:
        if default is None:
            default = lambda missing_key: missing_key
        self.default = default # sets self._default

    def default(self):
        return self._default

    def default(self, val):
        if callable(val):
            self._default = val
        else: # constant value
            self._default = lambda missing_key: val

    def __missing__(self, x):
        return self.default(x)

Of course, one can debate whether one wants to allow changing the default-function after initialisation, but that just means removing @default.setter and absorbing its logic into __init__.

Enabling introspection into the current (constant) default value could be added with two extra lines.

Subclass dict's __getitem__ method. For example, How to properly subclass dict and override __getitem__ & __setitem__

Need Your Help

React-Native and Intl polyfill required on Android device

javascript android react-native intl react-intl

I recently updated my Android Studio and many components/sdk and since then React-Intl complains about intl library missing, even though it was working fine before.

When to use .NET Settings vs config <appsettings>?

.net appsettings settings.settings

Are there any recommendations on when to use Application settings (not per user settings) vs. .config file &lt;appsettings&gt;?