1064

I came across the dict method get which, given a key in the dictionary, returns the associated value.

For what purpose is this function useful? If I wanted to find a value associated with a key in a dictionary, I can just do dict[key], and it returns the same thing:

dictionary = {"Name": "Harry", "Age": 17}
dictionary["Name"] == dictionary.get("Name")      # True

See also: Return a default value if a dictionary key is not available

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153
stensootla
  • 13,945
  • 9
  • 45
  • 68

16 Answers16

1558

It allows you to provide a default value if the key is missing:

dictionary.get("bogus", default_value)

returns default_value (whatever you choose it to be), whereas

dictionary["bogus"]

would raise a KeyError.

If omitted, default_value is None, such that

dictionary.get("bogus")  # <-- No default specified -- defaults to None

returns None just like

dictionary.get("bogus", None)

would.

Jean-François Corbett
  • 37,420
  • 30
  • 139
  • 188
unutbu
  • 842,883
  • 184
  • 1,785
  • 1,677
  • It's very useful in reinforcement learning that requires randomized initialization: e.g. `q_sa = q.get((s, action), random())` – Tjorriemorrie Feb 05 '15 at 12:46
  • 1
    Would this be the same as `dictionary.get("bogus") or my_default`? I've seen people use it in some cases and I was wondering if there's any advantage of using one instead of the other (other than readability) – Algorithmatic Dec 04 '15 at 21:57
  • 59
    @MustafaS: If `"bogus"` is a key in `dictionary` and `dictionary.get("bogus")` returns a value which evaluates to False in a boolean context (i.e. a Falsey value), such as 0 or an empty string, `''`, then `dictionary.get("bogus") or my_default` would evaluate to `my_default` whereas `dictionary.get("bogus", my_default)` would return the Falsey value. So no, `dictionary.get("bogus") or my_default` is not equivalent to `dictionary.get("bogus", my_default)`. Which to use depends on the behavior you desire. – unutbu Dec 04 '15 at 22:22
  • 10
    @MustafaS: For example, suppose `x = {'a':0}`. Then `x.get('a', 'foo')` returns `0` but `x.get('a') or 'foo'` returns `'foo'`. – unutbu Dec 04 '15 at 22:27
  • 10
    One possible caveat when using `dictionary.get('key')`: It can be confusing if values in the dictionary are `None`. Without specifying the return value (second optional argument) there is no way to verify if the key didn't exist or if its value is `None`. In this specific case I would consider using `try-except-KeyError`. – Aart Goossens Feb 17 '16 at 10:33
  • 2
    It's worth noting that the expression to specify the default value is evaluated in the "get" call, and is therefore evaluated on each access. A classic alternative (using either a KeyError handler or a predicate) is to evaluate the default value only if the key is missing. This allows a closure/lambda to be created once and evaluated on any missing key. – Tom Stambaugh Sep 14 '18 at 19:22
  • 2
    @AartGoossens Or you could use `if 'key' in dictionary`, to avoid using `try-except` and to make the code easier to understand. – Anonymous Nov 21 '20 at 23:41
  • @AartGoossens: Agreed. But the primary purpose of `get()` is to conveniently get a value with defined semantics from the dict, regardless whether the key is in the dict or not. This is the very definition and the very purpose of a default value. Using a specific default value to check whether the key is present in a dict is always a hack. – Johannes Overmann May 16 '23 at 12:25
  • Hasn't this been supplanted somewhat by defaultdict? Unless, you want a different default for every missing value. – Jiminion Aug 18 '23 at 14:17
226

What is the dict.get() method?

As already mentioned the get method contains an additional parameter which indicates the missing value. From the documentation

get(key[, default])

Return the value for key if key is in the dictionary, else default. If default is not given, it defaults to None, so that this method never raises a KeyError.

An example can be

>>> d = {1:2,2:3}
>>> d[1]
2
>>> d.get(1)
2
>>> d.get(3)
>>> repr(d.get(3))
'None'
>>> d.get(3,1)
1

Are there speed improvements anywhere?

As mentioned here,

It seems that all three approaches now exhibit similar performance (within about 10% of each other), more or less independent of the properties of the list of words.

Earlier get was considerably slower, However now the speed is almost comparable along with the additional advantage of returning the default value. But to clear all our queries, we can test on a fairly large list (Note that the test includes looking up all the valid keys only)

def getway(d):
    for i in range(100):
        s = d.get(i)

def lookup(d):
    for i in range(100):
        s = d[i]

Now timing these two functions using timeit

>>> import timeit
>>> print(timeit.timeit("getway({i:i for i in range(100)})","from __main__ import getway"))
20.2124660015
>>> print(timeit.timeit("lookup({i:i for i in range(100)})","from __main__ import lookup"))
16.16223979

As we can see the lookup is faster than the get as there is no function lookup. This can be seen through dis

>>> def lookup(d,val):
...     return d[val]
... 
>>> def getway(d,val):
...     return d.get(val)
... 
>>> dis.dis(getway)
  2           0 LOAD_FAST                0 (d)
              3 LOAD_ATTR                0 (get)
              6 LOAD_FAST                1 (val)
              9 CALL_FUNCTION            1
             12 RETURN_VALUE        
>>> dis.dis(lookup)
  2           0 LOAD_FAST                0 (d)
              3 LOAD_FAST                1 (val)
              6 BINARY_SUBSCR       
              7 RETURN_VALUE  

Where will it be useful?

It will be useful whenever you want to provide a default value whenever you are looking up a dictionary. This reduces

 if key in dic:
      val = dic[key]
 else:
      val = def_val

To a single line, val = dic.get(key,def_val)

Where will it be NOT useful?

Whenever you want to return a KeyError stating that the particular key is not available. Returning a default value also carries the risk that a particular default value may be a key too!

Is it possible to have get like feature in dict['key']?

Yes! We need to implement the __missing__ in a dict subclass.

A sample program can be

class MyDict(dict):
    def __missing__(self, key):
        return None

A small demonstration can be

>>> my_d = MyDict({1:2,2:3})
>>> my_d[1]
2
>>> my_d[3]
>>> repr(my_d[3])
'None'
Alexander McFarlane
  • 10,643
  • 9
  • 59
  • 100
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
  • [Playground link with these code](https://repl.it/Gz4w/latest) – Abhijeet Apr 07 '17 at 06:24
  • 1
    One more good test would be `if k in dict and dict[k]:` vs `if dict.get(k):`. This covers the situation when we need to check if key exists, and if 'yes' - what value?, something like: `dict = {1: '', 2: 'some value'}`. – TitanFighter Sep 16 '17 at 18:05
  • 11
    Please remember that default value gets evaluated regardless of the value being in dictionary, so instead of `dictionary.get(value, long_function())` one might consider using `dictionary.get(value) or long_function()` – Kresimir May 08 '18 at 10:34
  • 2
    @Kresimir The two methods are not the same, because `None` or a False-y value would default, while `dictionary.get()` would return the default value only if it is missing. – Anonymous Nov 21 '20 at 23:48
  • The `collections` module also has `defaultdict`, so no need to write a new class anymore. – Karl Sep 21 '21 at 14:46
37

get takes a second optional value. If the specified key does not exist in your dictionary, then this value will be returned.

dictionary = {"Name": "Harry", "Age": 17}
dictionary.get('Year', 'No available data')
>> 'No available data'

If you do not give the second parameter, None will be returned.

If you use indexing as in dictionary['Year'], nonexistent keys will raise KeyError.

Mattie
  • 20,280
  • 7
  • 36
  • 54
Mp0int
  • 18,172
  • 15
  • 83
  • 114
30

A gotcha to be aware of when using .get():

If the dictionary contains the key used in the call to .get() and its value is None, the .get() method will return None even if a default value is supplied.

For example, the following returns None, not 'alt_value' as may be expected:

d = {'key': None}
assert None is d.get('key', 'alt_value')

.get()'s second value is only returned if the key supplied is NOT in the dictionary, not if the return value of that call is None.

user1847
  • 3,571
  • 1
  • 26
  • 35
25

I will give a practical example in scraping web data using python, a lot of the times you will get keys with no values, in those cases you will get errors if you use dictionary['key'], whereas dictionary.get('key', 'return_otherwise') has no problems.

Similarly, I would use ''.join(list) as opposed to list[0] if you try to capture a single value from a list.

hope it helps.

[Edit] Here is a practical example:

Say, you are calling an API, which returns a JOSN file you need to parse. The first JSON looks like following:

{"bids":{"id":16210506,"submitdate":"2011-10-16 15:53:25","submitdate_f":"10\/16\/2011 at 21:53 CEST","submitdate_f2":"p\u0159ed 2 lety","submitdate_ts":1318794805,"users_id":"2674360","project_id":"1250499"}}

The second JOSN is like this:

{"bids":{"id":16210506,"submitdate":"2011-10-16 15:53:25","submitdate_f":"10\/16\/2011 at 21:53 CEST","submitdate_f2":"p\u0159ed 2 lety","users_id":"2674360","project_id":"1250499"}}

Note that the second JSON is missing the "submitdate_ts" key, which is pretty normal in any data structure.

So when you try to access the value of that key in a loop, can you call it with the following:

for item in API_call:
    submitdate_ts = item["bids"]["submitdate_ts"]

You could, but it will give you a traceback error for the second JSON line, because the key simply doesn't exist.

The appropriate way of coding this, could be the following:

for item in API_call:
    submitdate_ts = item.get("bids", {'x': None}).get("submitdate_ts")

{'x': None} is there to avoid the second level getting an error. Of course you can build in more fault tolerance into the code if you are doing scraping. Like first specifying a if condition

kevin
  • 1,107
  • 1
  • 13
  • 17
  • 2
    A good answer, posted before any of the others, which would have been upvoted more, and probably accepted, if you had posted some code examples (+1 from me, though) – Mawg says reinstate Monica Mar 03 '16 at 09:49
  • 2
    @Mawg I recently had a scraping project for my research. It was calling an API and parsing JSON files basically. I had my RA do it. One of the key issues he had was calling the key directly, when many keys are actually missing. I will post an example in the text above. – kevin Aug 13 '16 at 22:06
  • thanks for tackling the multi-dimensional aspect of this! Sounds like you can even just do {} instead of {'x': None} – bluppfisk Dec 03 '17 at 16:56
20

The purpose is that you can give a default value if the key is not found, which is very useful

dictionary.get("Name",'harry')
SiHa
  • 7,830
  • 13
  • 34
  • 43
hackartist
  • 5,172
  • 4
  • 33
  • 48
11

For what purpose is this function useful?

One particular usage is counting with a dictionary. Let's assume you want to count the number of occurrences of each element in a given list. The common way to do so is to make a dictionary where keys are elements and values are the number of occurrences.

fruits = ['apple', 'banana', 'peach', 'apple', 'pear']
d = {}
for fruit in fruits:
    if fruit not in d:
        d[fruit] = 0
    d[fruit] += 1

Using the .get() method, you can make this code more compact and clear:

for fruit in fruits:
    d[fruit] = d.get(fruit, 0) + 1
Daniel Holmes
  • 1,952
  • 2
  • 17
  • 28
jetpack_guy
  • 350
  • 2
  • 9
  • 12
  • 2
    While this is true, bear in mind that `d = defaultdict(int)` is even cleaner. Inner loop becomes `d[fruit] += 1`. Then again, probably `collections.Counter` is better still than the `defaultdict` version. The `.get` version may still be useful if you don't want to convert a `Counter` or `defaultdict` back to a `dict` or something like that. – ggorlen Dec 19 '20 at 04:06
10

Other answers have clearly explained the difference between dict bracket keying and .get and mentioned a fairly innocuous pitfall when None or the default value is also a valid key.

Given this information, it may be tempting conclude that .get is somehow safer and better than bracket indexing and should always be used instead of bracket lookups, as argued in Stop Using Square Bracket Notation to Get a Dictionary's Value in Python, even in the common case when they expect the lookup to succeed (i.e. never raise a KeyError).

The author of the blog post argues that .get "safeguards your code":

Notice how trying to reference a term that doesn't exist causes a KeyError. This can cause major headaches, especially when dealing with unpredictable business data.

While we could wrap our statement in a try/except or if statement, this much care for a dictionary term will quickly pile up.

It's true that in the uncommon case for null (None)-coalescing or otherwise filling in a missing value to handle unpredictable dynamic data, a judiciously-deployed .get is a useful and Pythonic shorthand tool for ungainly if key in dct: and try/except blocks that only exist to set default values when the key might be missing as part of the behavioral specification for the program.

However, replacing all bracket dict lookups, including those that you assert must succeed, with .get is a different matter. This practice effectively downgrades a class of runtime errors that help reveal bugs into silent illegal state scenarios that tend to be harder to identify and debug.

A common mistake among programmers is to think exceptions cause headaches and attempt to suppress them, using techniques like wrapping code in try ... except: pass blocks. They later realize the real headache is never seeing the breach of application logic at the point of failure and deploying a broken application. Better programming practice is to embrace assertions for all program invariants such as keys that must be in a dictionary.

The hierarchy of error safety is, broadly:

Error category Relative ease of debugging
Compile-time error Easy; go to the line and fix the problem
Runtime exception Medium; control needs to flow to the error and it may be due to unanticipated edge cases or hard-to-reproduce state like a race condition between threads, but at least we get a clear error message and stack trace when it does happen.
Silent logical error Difficult; we may not even know it exists, and when we do, tracking down state that caused it can be very challenging due to lack of locality and potential for multiple assertion breaches.

When programming language designers talk about program safety, a major goal is to surface, not suppress, genuine errors by promoting runtime errors to compile-time errors and promote silent logical errors to either runtime exceptions or (ideally) compile-time errors.

Python, by design as an interpreted language, relies heavily on runtime exceptions instead of compiler errors. Missing methods or properties, illegal type operations like 1 + "a" and out of bounds or missing indices or keys raise by default.

Some languages like JS, Java, Rust and Go use the fallback behavior for their maps by default (and in many cases, don't provide a throw/raise alternative), but Python throws by default, along with other languages like C#. Perl/PHP issue an uninitialized value warning.

Indiscriminate application of .get to all dict accesses, even those that aren't expected to fail and have no fallback for dealing with None (or whatever default is used) running amok through the code, pretty much tosses away Python's runtime exception safety net for this class of errors, silencing or adding indirection to potential bugs.

Other supporting reasons to prefer bracket lookups (with the occasional, well-placed .get where a default is expected):

  • Prefer writing standard, idiomatic code using the tools provided by the language. Python programmers usually (correctly) prefer brackets for the exception safety reasons given above and because it's the default behavior for Python dicts.
  • Always using .get forfeits intent by making cases when you expect to provide a default None value indistinguishable from a lookup you assert must succeed.
  • Testing increases in complexity in proportion to the new "legal" program paths permitted by .get. Effectively, each lookup is now a branch that can succeed or fail -- both cases must be tested to establish coverage, even if the default path is effectively unreachable by specification (ironically leading to additional if val is not None: or try for all future uses of the retrieved value; unnecessary and confusing for something that should never be None in the first place).
  • .get is a bit slower.
  • .get is harder to type and uglier to read (compare Java's tacked-on-feel ArrayList syntax to native-feel C# Lists or C++ vector code). Minor.

Some languages like C++ and Ruby offer alternate methods (at and fetch, respectively) to opt-in to throwing an error on a bad access, while C# offers opt-in fallback value TryGetValue similar to Python's get.

Since JS, Java, Ruby, Go and Rust bake the fallback approach of .get into all hash lookups by default, it can't be that bad, one might think. It's true that this isn't the largest issue facing language designers and there are plenty of use cases for the no-throw access version, so it's unsurprising that there's no consensus across languages.

But as I've argued, Python (along with C#) has done better than these languages by making the assert option the default. It's a loss of safety and expressivity to opt-out of using it to report contract violations at the point of failure by indiscriminately using .get across the board.

ggorlen
  • 44,755
  • 7
  • 76
  • 106
  • 1
    something else: ```python In [1]: from collections import defaultdict In [2]: d = defaultdict(list) In [3]: print(d.get('b')) None In [4]: print(d['b']) [] ``` so, for `defaultdict` you need to be careful how you want to trigger the "globally default" value. – Clint Eastwood Aug 26 '22 at 18:32
  • I disagree that using `try/catch` causes headaches, it can actually be very useful when paired with a solid error detection model. Slack notifications, emails, anything could be used instead of adding a silent `try/catch`. – treckstar Apr 25 '23 at 06:01
  • @treckstar That's not what's being discussed here. We're talking about dict `.get()`, which suppresses the error and does not send you a Slack message or email. Sure, you can add an `if dct.get("missing key") is None: # report error` but that's also not what's being discussed. I'm talking about _indiscriminately suppressing errors_ with `.get()` to create an illusion of safety, while actually allowing `None`s to run loose in your code, unhandled. You were linked here from a thread where you advocated OP silence their invariant error, suppressing the problem rather than solving it. – ggorlen Apr 25 '23 at 06:05
5

Why dict.get(key) instead of dict[key]?

0. Summary

Comparing to dict[key], dict.get provides a fallback value when looking up for a key.

1. Definition

get(key[, default]) 4. Built-in Types — Python 3.6.4rc1 documentation

Return the value for key if key is in the dictionary, else default. If default is not given, it defaults to None, so that this method never raises a KeyError.

d = {"Name": "Harry", "Age": 17}
In [4]: d['gender']
KeyError: 'gender'
In [5]: d.get('gender', 'Not specified, please add it')
Out[5]: 'Not specified, please add it'

2. Problem it solves.

If without default value, you have to write cumbersome codes to handle such an exception.

def get_harry_info(key):
    try:
        return "{}".format(d[key])
    except KeyError:
        return 'Not specified, please add it'
In [9]: get_harry_info('Name')
Out[9]: 'Harry'
In [10]: get_harry_info('Gender')
Out[10]: 'Not specified, please add it'

As a convenient solution, dict.get introduces an optional default value avoiding above unwiedly codes.

3. Conclusion

dict.get has an additional default value option to deal with exception if key is absent from the dictionary

AbstProcDo
  • 19,953
  • 19
  • 81
  • 138
5

One difference, that can be an advantage, is that if we are looking for a key that doesn't exist we will get None, not like when we use the brackets notation, in which case we will get an error thrown:

print(dictionary.get("address")) # None
print(dictionary["address"]) # throws KeyError: 'address'

Last thing that is cool about the get method, is that it receives an additional optional argument for a default value, that is if we tried to get the score value of a student, but the student doesn't have a score key we can get a 0 instead.

So instead of doing this (or something similar):

score = None
try:
    score = dictionary["score"]
except KeyError:
    score = 0

We can do this:

score = dictionary.get("score", 0)
# score = 0
אנונימי
  • 304
  • 2
  • 7
4

One other use-case that I do not see mentioned is as the key argument for functions like sorted, max and min. The get method allows for keys to be returned based on their values.

>>> ages = {"Harry": 17, "Lucy": 16, "Charlie": 18}
>>> print(sorted(ages, key=ages.get))
['Lucy', 'Harry', 'Charlie']
>>> print(max(ages, key=ages.get))
Charlie
>>> print(min(ages, key=ages.get))
Lucy

Thanks to this answer to a different question for providing this use-case!

dshanahan
  • 676
  • 5
  • 12
2

Short answer

The square brackets are used for conditional lookups which can fail with a KeyError when the key is missing.

The get() method is used from unconditional lookups that never fail because a default value has been supplied.

Base method and helper method

The square brackets call the __getitem__ method which is fundamental for mappings like dicts.

The get() method is a helper layered on top of that functionality. It is a short-cut for the common coding pattern:

try:
    v = d[k]
except KeyError:
    v = default_value  
Raymond Hettinger
  • 216,523
  • 63
  • 388
  • 485
0

It allow you to provide a default value, instead of get an error when the value is not found. persuedocode like this :

class dictionary():
    def get(self,key,default):
         if self[key] is not found : 
               return default
         else:
               return self[key]
Boyce Cecil
  • 97
  • 2
  • 8
  • I understand this is pseudocode, but `if self[key] is not found :` would crash, so you might as well just write it as normal Python so it's less confusing. – ggorlen Jul 04 '22 at 15:43
0

With Python 3.8 and after, the dictionary get() method can be used with the walrus operator := in an assignment expression to further reduce code:

if (name := dictonary.get("Name")) is not None
    return name

Using [] instead of get() would require wrapping the code in a try/except block and catching KeyError (not shown). And without the walrus operator, you would need another line of code:

name = dictionary.get("Name")
if (name is not None)
    return name
unjedai
  • 15
  • 6
0

For what purpose is this function useful?

Another use case where get() is useful is it induces a built-in function from a dictionary. As other answers mentioned, a default value can be specified for dict.get, which means the key itself can be returned if it's not in the dictionary, e.g. my_dict.get(key, key). This means we can use dict.get() to replace values very succintly.

For example, from dictionary dct = {1: 10}, we can create the function replacer = dct.get (type(mapper) returns builtin_function_or_method). Then this function can be mapped to replace values.

lst = [0, 1, 2, 3, 4]
new_list = list(map(replacer, lst, lst))   # [0, 10, 2, 3, 4]

It's, in fact, very fast to lookup values using the function induced by dict.get(). The following experiment shows that looking up via the function is over 2 times faster than looking up via the dictionary (it was done on Python 3.9.12).

import timeit
setup = "lst = [0,1]*10000; dct = {1: 10}; replacer = dct.get"
t1 = min(timeit.repeat("list(map(replacer, lst, lst))", setup, number=100))
t2 = min(timeit.repeat("[dct[k] if k in dct else k for k in lst]", setup, number=100))

print(t2 / t1)   # 2.707056842200316
cottontail
  • 10,268
  • 18
  • 50
  • 51
0

.get() gives you an "implicit" try: ... except:, making code cleaner and more robust when you get used to it.

Ate Somebits
  • 287
  • 1
  • 18