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/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/5KUUL5P5QQMIYSDO5DNK5DK5I6NRE3GA/
Code of Conduct: http://python.org/psf/codeofconduct/
