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 <luciano@ramalho.org> wrote:
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 <thisfred@gmail.com> wrote:
On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon <mark@hotpy.org> 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