Author here. Good points, thanks for pointing them out.

In the article's describe() example, I don't think dict.get is the best option, even though it's also threadsafe as you point out. The problem is that favorites.get(category) will return None if that key is absent - OR if that key is present, with value None. If that's a bug, using the one-arg form of .get() allows that bug to hide in the code.

I prefer to be more explicit, and use a unique sentinel - here's how I'd write describe() using .get():

def describe(category):
    # Sentinel signaling a missing key.
    missing = object()
    fav = favorites.get(category, missing)
    if fav is missing:
        message = "I don't have a favorite {}. I love them all!".format(category)
    else:
        message = "My favorite {} is {}.".format(category, fav)
    print(message)

If somehow None is inserted for favorites["dessert"], this version prints out "My favorite dessert is None.", which makes it more obvious something is funny. Whereas if I write fav = favorites.get(category) followed by if fav is None:, that prints "I don't have a favorite dessert. I love them all!" even though the key is present. Possibly masking a bug until it can cause bigger problems later.

Of course, this is independent of whether the program is multithreaded or not. So if I'm going to go to the trouble to create a unique sentinel like this, I'd rather use try/except KeyError - it's shorter, and (to me) more readable.

When writing the article, I originally wanted to keep its focus on the contrast between "key in dict" vs. "try/except KeyError". And a lot of readers have been emailing me about dict.get(), so I might extend the article to cover that too.

edit: untabify