The programmers that insist in using type hints in python usually are the ones that makes these mistakes. I think the main reason that these patterns do not make sense is because python is a dynamic language. If you turn off the part of your brain that thinks in types you realize that you can solve most of these in plain functions and dicts. Using default args as replacement to the builder pattern is just ridiculous. If you want to encode rules for creating data, that screams schema validation, not builder pattern.
Python type hints are hugely valuable both as a means of correctness checking, but also just as a means of documentation. It strikes me as incredibly shortsighted to say you can forget about types just because it’s a dynamic language. The types are absolutely still there and need thought about. They just aren’t defined or used in terms of allocation and management of memory.
> The types are absolutely still there and need thought about
Yes, if they aren't in the code, it just means the programmer has figure out and carry that around mentally when reading or writing code.
Usually with OOP several builders are composed together to express the creation of some data. These builders have functions with types, which define the rules for the creation of the objects.
My point is that the CarBuilder is not a real type that relates to the business, but something that we had to create to encode some behaviour/rules.
Some function that validates that a dict is a valid car is much more explicit that lots of different builder classes in my opinion.