[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)
Terry Reedy tjreedy at udel.edu
Wed Apr 22 08:01:20 CEST 2015
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4/21/2015 6:50 PM, Chris Barker wrote:
On Tue, Apr 21, 2015 at 11:58 AM, Paul Sokolovsky <pmiscml at gmail.com_ _<mailto:pmiscml at gmail.com>> wrote:
It does, and hope people won't be caught in "static typechecking" loop and consider other usages too.
I an interested is using type hints for automatic or at least semi-automatic generation of tests, in particular for parameters hinted as generic and abstract. A parameter "ints: Iterable(int)" should be work with empty, length 1, and longer tuples, lists, sets, dicts (with int keys) and a custom class. Unless there is supplementary doc otherwise, it should handle negative, 0, and positive ints, small and large, in regular and random patterns. (Thinking about this more, some of this could be done without the PEP being approved, but there has to be some syntax for test generator input information, and using the standard vocabulary of typing instead of inventing something would be easier.)
I"m confused -- from the bit I've been skimming the discussion, over on python-ideas, and now here, is that this is all about "static typechecking".
The PEP is about a) defining type hints as the primary use of annotations* and b) adding a new module to standardize type hints instead of having multiple groups define multiple variations on the theme. The urgency of developing a standard now is that there are at least two or three independent efforts.
- http://www.artima.com/weblogs/viewpost.jsp?thread=85551 (2004) makes it clear that Guido thought of static typing first and annotations second, in the form added to 3.0 years later, as an implementation thereof.
The primary motivation of the people working on the new module is static typechecking by 3rd party programs. This seems to be Guido's primary interest and what he believes will be the primary use. It is also the primary promotional argument since type checking already exists.
However, this does not stop others from having other motivations and making other uses of the information once available.
It's not about run-time type checking.
The PEP does not prevent that, and will make it more feasible by standardizing on one system.
It's not about type-base performance optimization.
Nothing is planned for CPython, but type hints are already being used by MicroPython for this purpose. (To me, this is one of the pluses of it having targeted 3.3.)
It's not about any use of annotations other than types.
Right, but there are multiple possible uses for type information.
What is it about other than static typechecking?
There is also documentation. Type hints are partially an alternative to stylized entries in doc strings. A program might combine the two or check consistency.
-- Terry Jan Reedy
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]