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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
