A note here:
Earlier in the conversation about standardizing type hinting, I (among
others) was interested in applying it to C-level static typing (e.g.
Cython).
Guido made it very clear that that was NOT a goal of type hints —
rather, they were to be used for dynamic, python style types — so a
“list” is guaranteed to act like a list in python code, but not to
have the same underlying binary representation.
We could still use the same syntax for things like Cython, but they
would have a different meaning.
And a JIT compiler may not benefit from the hints at all, as it would
have to check the actual type at run-time anyway.
-CHB
Sent from my iPhone
> On Jul 20, 2018, at 2:32 AM, Stefan Behnel <stefan...@behnel.de> wrote:
>
> Michael Hall schrieb am 19.07.2018 um 15:51:
>> While I am aware of projects like Cython and mypy, it seems to make sense
>> for CPython to allow optional enforcement of type hints, with compiler
>> optimizations related to it to be used. While this would not receive the
>> same level of performance benefits as using ctypes directly, there do
>> appear to be various gains available here.
>
> Well, first of all, a C level type check at runtime is quite fast compared
> to a byte code dispatch with stack argument handling, and can be done
> regardless of any type hints. There are various code patterns that would
> suggest a certain type ("x.append()" probably appends to a list, "x.get()"
> will likely be a dict lookup, etc.), and that can be optimised for without
> static type declarations and even without any type hints.
>
> Then, the mere fact that user code says "a: List" does not help in any way.
> Even "a: list" would not help, because any behaviour of that "list" might
> have been overridden by the list subtype that the function eventually
> receives.
>
> The same applies to "x: float". Here, in order to gain speed, the compiler
> would have to generate two separate code paths through the entire function,
> one for C double computations, and one for Python float subtypes. And then
> exponentiate that by the number of other typed arguments that may or may
> not contain subtypes. Quite some overhead.
>
> It's unclear if the gain would have any reasonable relation to the effort
> in the end. Sure, type hints could be used as a bare trigger for certain
> optimistic optimisations, but then, it's cheap enough to always apply these
> optimisations regardless, via a C type check.
>
> Stefan
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
