For example, it doesn't have a built-in way to make a dictionary-whose-keys-must-be-integers (so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None).
I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
Technically, dict.get() returns None if the item isn't found and you don't provide a different value for its default.
thedictionary[b] would throw a KeyError on the other hand.
One could always subclass dict if they wanted to ensure the keys were always integers or whatever.
> I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).
Not sure if you're arguing for a stronger type system or having the language promote the string to an int as (I've heard) other scripting languages do.
Though, once you figure out the language doesn't automagically parse files for you you're well on the way to finding more fun and exciting ways to get python to throw error messages at you.
Type hinting does not guarantee to catch everything, but for Python proponents 95% is apparently "good enough".
It's definitely a neat feature when writing an application from scratch that interfaces with few other modules or only the well-tested ones.
You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language.
Need proof? Try doing this:
a = 3
b = “3”
c = a + b
> having to use lots of assert(isinstance(arg, type))
Python has type hinting now, try using a current version of Python and this isn’t needed.