On Thu, Jul 19, 2018 at 10:02 AM, Eric Fahlgren wrote:

On Thu, Jul 19, 2018 at 6:52 AM Michael Hall wrote:

...

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.

​Just to make sure I understand: In other words, they would no longer be "hints" but "guarantees". This would allow an optimizer pass much greater latitude in code generation, somehow or other.​

For purposes of illustration (this is not a proposal, just for clarification):

@guaranteed_types def my_sqrt(x:c_double) -> c_double: ...

would tell the compiler that it's now possible to replace the general PyObject marshalling of this function with a pure-C one that only accepts doubles and woe be unto those who use it otherwise.

Yes, Though this would likely require introducing new grammar of some sort to have it treated by the compiler as a guarantee, rather than a hint.

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 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/