<div dir="ltr"><div><div><div>Ludovic,<br><br></div>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.<br><br></div>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:<br><br>  def longest(a, b):<br></div><div>      return a if len(a) >= len(b) else b<br><br></div><div>Now I start adding annotations, and I change this to:<br><br></div><div>  def longest(a: str, b: str) -> str:<br>      return a if len(a) >= len(b) else b<br><br></div><div>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?<br><br></div><div>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.<br><br></div><div>Salut,<br><br></div><div>--Guido<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 21, 2014 at 11:23 AM, Ludovic Gasc <span dir="ltr"><<a href="mailto:gmludo@gmail.com" target="_blank">gmludo@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">Hi Nick,</p>
<p dir="ltr">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.</p>
<p dir="ltr">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...).<br>
To my knowledge, you don't have the same number of libraries to do that with another dynamic language.<br>
It means that in Python community we have this problematic.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.<br>
They don't use only this strategy to improve performance, but it's the biggest visible part in example codes I've seen.</p><p>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.</p>
<p dir="ltr">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..."<br>For me, Python has the right compromise to write quickly readable source code and performance possibilities to speed up your code.</p><p>More we have primitives in CPython to build performant applications, more it will be easier to convince people to use Python.</p>
<p dir="ltr">Regards. <br>
--<br>
Ludovic Gasc</p><div><div class="h5">
<div class="gmail_quote">On 21 Dec 2014 02:15, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 December 2014 at 09:55, Ludovic Gasc <span dir="ltr"><<a href="mailto:gmludo@gmail.com" target="_blank">gmludo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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:</div><div><br></div><div>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 ?</div><div><br></div><div>It could possible to have better performance one day with Type Hinting like you have with Cython (explicit types declaration) or PyPy (guessing types) ?</div></div></blockquote><br></div><div class="gmail_quote">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.<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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*.<br><br>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).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br>Nick.<br><br></div><div class="gmail_extra">-- <br><div>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>
</blockquote></div>
</div></div></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>