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

[Ronan Lamy]

Le 25/04/15 04:07, Steven D'Aprano a écrit :
> 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.

The PEP doesn't explain how to do that. And even if it's possible, such 
types wouldn't be very useful as they're not stable under any arithmetic 
operation (e.g. <int16> + <int16> doesn't necessarily fit in int16).

>> * 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.

Yes, talking about performance in the context of PEP 484 is a red 
herring, that's what I'm saying.