exercise5/answer.py: .get() with a default and .get() without — why both forms?

[dab00gieman]

answers/exercise5/answer.py uses both forms:

print(weirdo_1.get("fast", "sluggish"))
...
michael = {"michael.": "python && rust"}
print(michael.get("car"))

The first supplies a fallback ("sluggish"), the second returns None for the missing "car" key. Was the contrast deliberate — demonstrating that .get() has an optional default — and is there a reason the "michael." key includes a trailing period?

[mgkvibez]

Yes — the contrast is the point of exercise 5, and the trailing period is a deliberate key-exactness demo. Breaking down answers/exercise5/answer.py:

print(weirdo_1.get("fast", "sluggish"))   # None? no — "sluggish"
...
print(michael.get("car"))                  # None, no error

The two forms teach different halves of .get():

• weirdo_1.get("fast", "sluggish") — the "fast" key doesn't exist, so .get() returns the supplied default. Demonstrates the optional second argument.
• michael.get("car") — "car" doesn't exist and no default is given, so you get None instead of an exception. Demonstrates the default-free form and its None return.

The contrast that makes this land is with square brackets: michael["car"] raises KeyError, .get("car") returns None, .get("car", "unknown") returns "unknown". The file uses michael["michael."] directly for the existing key and .get() for the missing one, which is the right instinct — one more comment noting the KeyError contrast would complete the lesson.

The trailing period in "michael." is doing real work, not a typo: dict keys are exact string matches — "michael." and "michael" are different keys, and the dot is a perfectly legal character. It quietly demonstrates that keys are compared literally, no trimming, no normalization. If the intent was only to show a value being retrieved, plain "michael" would do; keeping the period plus a one-line comment ("keys match exactly — the dot is part of the key") turns an odd-looking string into the actual lesson.