Hi everyone, Once upon a time Python was a purely duck typed language. Then came along abstract based classes, and some nominal typing starting to creep into the language. If you guarded your code with `isinstance(foo, Sequence)` then I could not use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced to use nominal typing; inheriting from Sequence, or explicitly registering as a Sequence. Then came type hints. PEP 484 explicitly said that type hints were optional and would *always* be optional. Then came along many typing PEPs that assumed that type hints would only used for static typing, making static typing a bit less optional. Not only that, but the type system proposed by many of these PEPs was clearly nominal, not structural. PEP 544 supports structural typing, but to declare a structural type you must inherit from Protocol. That smells a lot like nominal typing to me. Then came PEP 563 and said that if you wanted to access the annotations of an object, you needed to call typing.get_type_hints() to get annotations in a meaningful form. This smells a bit like enforced static typing to me. Then came PEP 634 (structural pattern matching). Despite having the word 'structural' in the name, PEP 634 insists on nominal typing to distinguish between sequences and mappings. Nominal typing in a dynamically typed language makes little sense. It gains little or no safety, but restricts the programs you can write. Because a class can claim to be a nominal type, but not match it structurally, it can appear to be type safe but fail at runtime. Conversely nominal typing errors can result in failures where structurally typed programs would work. An extreme example of that is this: # Some magic code to mess with collections.abc.Sequence
match {}: ... case []: ... print("WTF!") ... WTF!
With duck typing this would be impossible (unless you use ctypes to mess with the dict object). To be fair, nominal typing is not always a problem. All exceptions must inherit from BaseException, and it doesn't seem to be a problem in practice. So, lets stick to our promise that type hints will always be optional, and restore duck typing. I'm not suggesting that we get rid type hints and abstract base classes. They are popular for a reason. But let's treat them as useful tools, not warp the rest of the language to fit them. Cheers, Mark. Quick summaries of type systems: https://en.wikipedia.org/wiki/Nominal_type_system https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedia.org/wiki/Duck_typing Or, if you're really keen: https://www.cis.upenn.edu/~bcpierce/tapl/