The use-case for dynamic typing was that I was decoding a large JSON data structure that could easily have thousands of different fields nested 10+ levels deep. Go's standard json library usually recommends that you define a struct type to hold the result of the decode, tagging field names with the `json` annotation. This obviously doesn't work when you only care about a few dozen of the several thousand possible fields. There is fortunately an escape hatch where you can declare a field as interface{} to say "Any type of data goes here; I'll downcast it later, and just trust me on the type", but then you have to litter your code with downcasts.
Python just hands you back a dict of lists, and you pull out the information you want, no type declarations needed.
The "user-defined types like built-ins" lets you build libraries where you can use the basic language structures on the data structure itself, without having to convert to an intermediate form. For example, the Python bindings to Amazon S3 let you access files through dictionary notation. BeautifulSoup lets you iterate over child nodes with a for loop, or access attributes as a dict. NumPy lets you use standard arithmetic operators on matrices. Judicious use of this in libraries makes the resulting code much briefer.
Python just hands you back a dict of lists, and you pull out the information you want, no type declarations needed.
The "user-defined types like built-ins" lets you build libraries where you can use the basic language structures on the data structure itself, without having to convert to an intermediate form. For example, the Python bindings to Amazon S3 let you access files through dictionary notation. BeautifulSoup lets you iterate over child nodes with a for loop, or access attributes as a dict. NumPy lets you use standard arithmetic operators on matrices. Judicious use of this in libraries makes the resulting code much briefer.