Now, given the terms I used in the last e-mail, it does worry me that
the push towards supporting STATIC TYPING in Python sometimes ignores
the needs of people who use the other typing disciplines. For example,
Pydantic is an example of using type hints for GOOSE TYPING.
And it alwo worries me that many of those not concerned with STATIC
TYPING are not following closely the decisions being made in the 19
(and counting) typing PEPs., some of which affect everyone who uses
Python.
Here are two examples:
PEP 484 DISMISSES THE NUMBERS ABCs
Direct quote from section "The Numeric Tower" [0]:
"There are some issues with these ABCs".
[0] https://www.python.org/dev/peps/pep-0484/#the-numeric-tower
No further explanation is given. The PEP then proposes ad-hoc rules to
support int, float and complex, leaving users of the Numbers ABCs,
Fraction, Decimal, and the huge NumPy community in the dark as to how
to handle other numeric types.
Now, I understand that the Numeric tower, as defined, cannot be used
for STATIC TYPING because the root class—Number—has no methods. Also,
there are deeper arguments regarding the soundness of that hierarchy.
See for example "Bad Ideas In Type Theory" [1].
[1] https://www.yodaiken.com/2017/09/15/bad-ideas-in-type-theory/
However, I think a package in the standard library, and more
importantly, the users of that package, deserve more attention.
If PEP 484 et. al. wants to serve all the Python community, it must be
part of its mission to address the problem of the Numbers ABCs, either
fixing it, or deprecating it while proposing something better, but not
creating an ad-hoc rule for three built-in types, ignoring all others.
PEP 563 EMBRACES THEN DEPRECATES ALL OTHER USES OF ANNOTATIONS
Section "Non-typing usage of annotations" [2] of PEP 563 starts with:
"While annotations are still available for arbitrary use besides type
checking..."
but ends in a very different tone:
"uses for annotations incompatible with the aforementioned PEPs should
be considered deprecated."
[2] https://www.python.org/dev/peps/pep-0563/#non-typing-usage-of-annotations
I think if more eyes beyond the STATIC TYPING community were looking
at the PEP, that inconsistency would have been flagged and dealt with
in some way.
OUR PROBLEM
There is a rift that need to work to close in the Python community.
Some people invested in STATIC TYPING are involved with million-line
codebases where performance is paramount and the cost of bugs may be
very high, and that creates a big motivation to use Python in a more
constrained way. They are not paying attention to other uses of type
hints—which are no deviations at all, because PEP 3107 explicitly
encouraged people to experiment with the annotations. If that is
deprecated, more people should be part of the conversation—as we are
seeing now.
On the other hand, most people who were attracted to Python *because*
of the flexibility of DUCK TYPING and GOOSE TYPING perhaps don't
follow the typing PEPs so closely—there are many, and most are pretty
hard to read, by the nature of the subject matter.
A BEAUTIFUL BRIDGE
PEP 544 was a *huge* step forward to bridge the gap between static
typing and duck typing in the language. Thank you very much for all
who proposed and implemented it. That's the kind of bridge we need!
(The `SupportsFloat` and similar protocols introduced with PEP 544 are
a way to test number types when they are not limited to float, int and
complex. But they expose some inconsistencies, and we still should do
something about the Numbers ABCs, IMHO)
GOING FORWARD
I think the PEP 563 v. PyDantic et. al. case is a very good
opportunity for us to think of ways to engage in dialog with the
different parts of the Python community on how they use types in the
language, considering STATIC TYPING, DUCK TYPING, STATIC DUCK TYPING,
GOOSE TYPING, without dismissing any of these styles.
If typing.get_type_hints is offered as a bridge for runtime uses of
type hints, it must work well and its shortcomings must be documented
as part of the official Python documentation, so that everyone knows
how reliable they are.
And in the future, if people come up with some new way of handling
types, every new addition must be considered in light of existing
typing styles—after a good, broad conversation involving different
user bases.
Cheers,
Luciano
On Tue, Apr 20, 2021 at 7:35 PM Luciano Ramalho
I am not taking sides now, but I want to share with you a useful diagram to reason about typing support in Python.
I struggled to explain what Python offers until I came up with this diagram:
https://standupdev.com/wiki/doku.php?id=python_protocols#the_typing_map
The Typing Map has two orthogonal axis:
- when are types checked: -- runtime checking -- static checking
- how are type checked: -- structural types -- nominal types
The quadrants are informally labeled with the terms in ALL CAPS below.
Traditionally, mainstream languages supported one of two diagonally opposite quadrants: STATIC TYPING and DUCK TYPING.
Now the situation is more complicated.
- Java supports only STATIC TYPING: static checking of nominal types; Python started supporting nominal types with PEP 484
- Before ABCs, Python supported only DUCK TYPING: runtime checking of structural types;
- With ABCs, Python started supporting GOOSE TYPING (a term invented by Alex Martelli, in cc because I just quoted him): runtime checking of nominal types (with subclass hook which is a backdoor to support explicit checks on structural types as well);
- With PEP 544, Python started supporting STATIC DUCK TYPING: static checking of structural types;
There are languages that support multiple quadrants:
- TypeScript, like Python, supports all four quadrants.
- Go supports STATIC TYPING, but it also famously popularized STATIC DUCK TYPING, and even supports GOOSE TYPING with features like type assertions and type switches [1] designed for explicit runtime checking of nominal or structural types.
[1] https://tour.golang.org/methods/16
The Typing Map will be featured in my upcoming PyCon US talk [2]
[2] https://us.pycon.org/2021/schedule/presentation/80/
Cheers,
Luciano
PS. If you are aware of other languages that support more than one of these quadrants, please let me know!
On Tue, Apr 20, 2021 at 6:53 PM Eric Casteleijn
wrote: On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon wrote:
... 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.
Note that to implement a protocol you do not have to inherit from anything. You create a structural type that subclasses Protocol, but then any object that satisfies that protocol can be passed where that type is expected, without having to inherit anything, so I would argue that this really is structural typing.
-- - eric casteleijn (he/him) _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/R3VP4KOR... Code of Conduct: http://python.org/psf/codeofconduct/
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg