[Python-Dev] Type hints -- a mediocre programmer's reaction

Steven D'Aprano steve at pearwood.info
Sat Apr 25 05:07:06 CEST 2015


On Sat, Apr 25, 2015 at 02:05:15AM +0100, Ronan Lamy wrote:

> * Hints have no run-time effect. The interpreter cannot assume that they 
> are obeyed.

I know what you mean, but just for the record, annotations are runtime 
inspectable, so people can (and probably have already started) to write 
runtime argument checking decorators or frameworks which rely on the 
type hints.


> * PEP484 hints are too high-level. Replacing an 'int' object with a 
> single machine word would be useful, but an 'int' annotation gives no 
> guarantee that it's correct (because Python 3 ints can have arbitrary 
> size and because subclasses of 'int' can override any operation to 
> invoke arbitrary code).

Then create your own int16, uint64 etc types.


> * A lot more information is needed to produce good code (e.g. “this f() 
> called here really means this function there, and will never be 
> monkey-patched” – same with len() or list(), btw).
> * Most of this information cannot easily be expressed as a type
> * If the interpreter gathers all that information, it'll probably have 
> gathered a superset of what PEP484 can provide anyway.

All this is a red herring. If type hints are useful to PyPy, that's a 
bonus. Cython uses its own system of type hints, a future version may be 
able to use PEP 484 hints instead. But any performance benefit is a 
bonus. PEP 484 is for increasing correctness, not speed.



-- 
Steve


More information about the Python-Dev mailing list