[Python-ideas] Type Hinting - Performance booster ?

[Guido van Rossum]

Ludovic,

If I understand you correctly you would like type annotations to be used to
speed up Python programs. You are not alone, but it's a really hard
problem, because nobody wants their program to break. I think that
eventually this will be possible, but in the short term, it would be a
much, much bigger effort to create such a compiler than it is just to
define (and reach agreement on) the syntax for annotations. I like to take
smaller steps first, especially when it comes to defining syntax. Maybe
once we have a standard type hinting notation someone will write a compiler.

In the meantime, let me give you an example of why it's such a hard
problem. Suppose I have created a library that contains a function that
finds the longest of two strings:

  def longest(a, b):
      return a if len(a) >= len(b) else b

Now I start adding annotations, and I change this to:

  def longest(a: str, b: str) -> str:
      return a if len(a) >= len(b) else b

But suppose someone else is using the first version of my library and they
have found it useful for other sequences besides strings, e.g. they call
longest() with two lists. That wasn't what I had written the function for.
But their program works. Should it be broken when the annotations are
added? Who gets the blame? How should it be fixed?

Now, I intentionally chose this example to be quite controversial, and
there are different possible answers to these questions. But the bottom
line is that this kind of situation (and others that can be summarized as
"duck typing") make it hard to create a Python compiler -- so hard that
nobody has yet cracked the problem completely. Maybe once we have agreed on
type hinting annotations someone will figure it out. In the meantime, I
think "offline" static type checking such as done by mypy is quite useful
in and of itself. Also, IDEs will be able to use the information conveyed
by type hinting annotations (especially in stub files). So I am content
with limiting the scope of the proposal to these use cases.

Salut,

--Guido


On Sun, Dec 21, 2014 at 11:23 AM, Ludovic Gasc <gmludo at gmail.com> wrote:
>
> Hi Nick,
>
> Thanks for your answer. I understand primary goal, I'm not completely
> naive on this question: A long time ago, I used a lot Type Hinting with PHP
> 5.
>
> Nevertheless, in Python community, you can find a lot of libraries to
> improve performance based on types handling with different optimization
> strategies  (numba, pypy, pythran, cython, llvm-py, shedskin...).
> To my knowledge, you don't have the same number of libraries to do that
> with another dynamic language.
> It means that in Python community we have this problematic.
>
> It's like with async pattern, in Python you have a plenty of libraries
> (Twisted, eventlet, gevent, stackless, tornado...) and now, with AsyncIO,
> the community should converge on it.
>
> And yes, I understand that it's almost impossible to create a silver
> bullet to improve automagically performance, but, as with my simple dev
> eyes, the common pattern I see with pythran, cython... is the type handling.
> They don't use only this strategy to improve performance, but it's the
> biggest visible part in example codes I've seen.
>
> Guido: " optimizers have been quite successful without type hints"  <=
> Certainly, but instead of to loose time to try to guess the right data
> structure, maybe it could be faster that the developer gives directly what
> he wants.
>
> To be honest, I'm a little bit tired to listen some bias like "Python is
> slow", "not good for performance", "you must use C/Java/Erlang/Go..."
> For me, Python has the right compromise to write quickly readable source
> code and performance possibilities to speed up your code.
>
> More we have primitives in CPython to build performant applications, more
> it will be easier to convince people to use Python.
>
> Regards.
> --
> Ludovic Gasc
> On 21 Dec 2014 02:15, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
>> On 21 December 2014 at 09:55, Ludovic Gasc <gmludo at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm only a simple Python developer, not a Type Hinting expert and I
>>> don't know if you already discuss about that somewhere, but:
>>>
>>> With the future official support of Type Hinting in Python, is it means
>>> that CPython could use this pieces of information to store variables with
>>> more efficient data structures, not only check types ?
>>>
>>> It could possible to have better performance one day with Type Hinting
>>> like you have with Cython (explicit types declaration) or PyPy (guessing
>>> types) ?
>>>
>>
>> The primary goals of the type hinting standardisation effort are
>> improving program correctness (through enhanced static analysis) and API
>> documentation (through clearer communication of expectations for input and
>> output, both in the code, in documentation, and in IDEs). It should also
>> allow the development of more advanced techniques for function signature
>> based dispatch and other forms of structured pattern matching.
>>
>> From a performance perspective though, CPython already has a wide array
>> of fast paths for particular builtin types - being able to communicate
>> those assumptions more clearly won't automatically make it easier to speed
>> them up further (or add more in a maintainable fashion). There's no
>> *philosophical* objection to such changes (other than "simplicity is a
>> virtue"), there's just a long track record of previous attempts like psyco
>> and Unladen Swallow that make it clear that the problem is genuinely *hard*.
>>
>> There's also the fact that with both Numba and PyPy now supporting
>> selective JIT acceleration of decorated functions within the context of a
>> larger CPython application, as well as Cython's existing support for
>> precompilation as a C extension, the pattern of profiling to find
>> performance critical areas, and finding ways to optimise those, now seems
>> well established. (Hence my suggestion the other day that we could likely
>> use an introductory how to guide on performance profiling, which could also
>> provide suggestions for optimisation tools to explore once the hot spots
>> have been found).
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141221/f3697a2b/attachment-0001.html>