Does the Primitive Obsession code smell apply to Python?

The simple answer here is 'yes': primitive obsession is still an issue in dynamically typed languages. The longer answer is that the issue is somewhat different in a dynamically typed language than a statically-typed one. I'm going to use Python as an example.

So the first bit of nuance is that in Python and similar languages, there aren't really 'primitives' in the first place. There are built-in types but they are objects. I only think we can mostly ignore this, but not completely. For most intents and purposes, they are used just like primitives are in other languages.

The other nuance is that in a dynamically-typed language, dependencies are not really defined by the type of an object, but rather by the operations it supports. For (somewhat of a silly) example, if I have a function that will add all the items in a sequence together, there's nothing stopping me from passing in a list of custom objects that support the __add__ method. This effectively means it's harder to create a primitive obsessed API but as Flater noted in comments on another answer, it doesn't prevent you from improperly using 'primitives' in a sub-optimal way.

The most common primitive obsession error (IMO) that I see often is the use of primitive numeric types to represent money. Using a decimal type is typically better than float, but it's still inappropriate. Money has special rules and passing it around as a bare number will often result in bugs and hamper the evolution of an application. For example, I once was talking to someone about an application they were involved in that used integer types for money. Then later, integer type they used was too small. They went through and changed all the integers representing money to doubles. I consider that two mistakes. So first off, consider trying to find every instance of an integer being used in a financial application and then determine what it's trying to represent. That's a major PITA in itself. Instead of using a primitive for money, a better solution is to define a Money type. It can be stupid simple initially: don't over-design things. But once you've done that, if you need to add a capability such as a wider range or support conversions, you can often fix that in one spot. And if you need to find all the places it's used, it's far easier to locate. Can you make a primitive obsession mistake like using base numeric types for money in a dynamically-typed language? Absolutely.

On the other hand, in my experience, dynamically typed languages make reusing existing types easier and I therefore don't feel the need to create as many custom types as I would in a statically-typed language. But you should still be considering whether a custom type is warranted and largely for the same reasons that you would in a statically-typed language.