Allow default as kwarg in dict.get()

ericatkin · April 4, 2026, 3:33am

Allow `default` keyword argument in dict.get() method

opened 02:51PM - 27 Sep 24 UTC

closed 01:48PM - 16 Sep 25 UTC

type-feature interpreter-core

# Feature or enhancement ### Proposal: ## Background The `dict.get()` method …is a commonly used feature in Python for retrieving values from dictionaries with a fallback option. Currently, it accepts positional arguments for the key and default value. However, allowing a keyword argument for the default value could enhance code readability and align with Python's philosophy of explicit naming. ## Current Behavior Consider the following code: ```python my_dict = {"a": 1, "b": 2, "c": 3} print(my_dict.get("b", "Not found")) ``` This works as expected. However, when attempting to use a keyword argument: ```python print(my_dict.get("b", default="Not found")) ``` It raises a `TypeError`: ``` Traceback (most recent call last): File "/path/to/script.py", line 3, in <module> print(my_dict.get("b", default="Not found")) TypeError: dict.get() takes no keyword arguments ``` ## Proposed Enhancement Allow the use of the `default` keyword argument in the `dict.get()` method. This would make the code more explicit and easier to read, especially in complex expressions or when the default value is a long expression. Proposed syntax: ```python my_dict.get("key", default="default_value") ``` ## Rationale 1. **Readability**: This change aligns with PEP 20 (The Zen of Python), specifically the principle "Explicit is better than implicit." Using a keyword argument makes the intention clearer, especially when the default value is complex or when the method call is part of a larger expression. 2. **Consistency**: Many Python built-in functions and methods allow both positional and keyword arguments for optional parameters (e.g., `sorted(iterable, key=None, reverse=False)`). This change would bring `dict.get()` in line with this common pattern. 3. **Backwards Compatibility**: This change would be backwards compatible, as it only adds functionality without altering existing behavior. 4. **Code Style**: It adheres to PEP 8 guidelines for function calls, allowing for more readable code when line length is a concern. ## Implementation Considerations - The current positional argument for the default value should still be supported for backwards compatibility. - The keyword argument should take precedence if both are provided, with a potential deprecation warning for using both simultaneously. ## Conclusion Introducing a `default` keyword argument to `dict.get()` would improve code readability and align with Python's design principles. It represents a small but meaningful enhancement to one of Python's most frequently used methods. ### Has this already been discussed elsewhere? This is a minor feature, which does not need previous discussion elsewhere ### Links to previous discussion of this feature: _No response_

I’ve read through the discussion on the ticket and I have an argument for the change that was not brought up, however, in closing the ticket picnixz asked that any further discussion originate here.

I have a need to transform a data structure and I’ve used a comprehension. The new object selects values from either a list of dicts (new_values), a list of objects (old_values) or not at all if they key is missing from both. Which list is sourced will vary from key to key. The value section of the comprehension therefore needs to be the same. I tried to use partial to normalize the getter, as when a key’s value will be derived from a dict, I need a default for get (I specifically need False, not the falsey None). The objects are instances of an adapter class to an external system that guarantees a boolean attribute for any name.

[
    {inner_k: v(inner_k) for inner_k in inner_keys}
    for outer_k in outer_keys
    if (
        v := partial(new_values[outer_k].get, default=False)
        if outer_k in new_values else
        outer_k in old_values and old_values[outer_k].__getattr__
    )
]

A convoluted circumstance, but the moral of the story is, default as a positional-only second argument renders dict.get() unusable with partial if you need a default. Perhaps others can think of a simpler example of a use of partial with dict.get().

The following solution works fine, but I can get pedantic and the partial approach not working when is seems like it should was a sliver in my mind

[
    {inner_k: v(inner_k) or False for inner_k in inner_keys}
    for outer_k in outer_keys
    if (
        v := new_values[outer_k].get
        if outer_k in new_values else
        outer_k in old_values and old_values[outer_k].__getattr__
    )
]

The 1-3% performance hit does give me pause, but that is the only argument I find compelling against the change. The constraint is surprising and as others have pointed out, makes dict not implement collections.abc.Mapping. At the very least, the docs should explain that the positional-only constraint exists for significant performance reasons despite the inconsistencies it creates.

mikeshardmind · April 4, 2026, 4:01am

functools.Placeholder exists for this use case already.

jamesdow21 · April 4, 2026, 4:03am

Python 3.14 added functools.Placeholder that can be used to allow partial to work the way you want

partial(dict.get, Placeholder, default)

ericatkin · April 5, 2026, 4:29pm

Great. Thank you for Placeholder.

I’d still put a note in the docs acknowledging this aberration and that it is intentional.