[Python-Dev] Type hints -- a mediocre programmer's reaction

[Ronan Lamy]

Le 24/04/15 19:45, Paul Sokolovsky a écrit :
> Hello,
>
> On Fri, 24 Apr 2015 18:27:29 +0100
> Ronan Lamy <ronan.lamy at gmail.com> wrote:
>
>>>> PyPy's FAQ
>>>> has an explanation of why type hints are not for performance.
>>>> http://pypy.readthedocs.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance
>>>
>>> You probably intended to write "why type hints are not for *PyPy's*
>>> performance". There're many other language implementations and
>>> modules for which it may be useful, please don't limit your
>>> imagination by a single case.
>>
>> Those points apply to basically any compliant implementation of
>> Python relying on speculative optimisation. Python is simply too
>> dynamic for PEP484-style hints to provide any useful performance
>> improvement targets.
>
> What's your point - saying that type annotations alone not enough to
> achieve the best ("C-like") performance, which is true, or saying that
> if they are alone not enough, then they are not needed at all, which
> is ... strange ?

My point is that the arguments in the PyPy FAQ aren't actually specific 
to PyPy, and therefore that the conclusion, that hints are almost 
entirely useless if you’re looking at performance, holds in general.
So let me restate these arguments in terms of a generic, 
performance-minded implementation of the full Python language spec:

* Hints have no run-time effect. The interpreter cannot assume that they 
are obeyed.
* 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).
* 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.

>>> And speaking of PyPy, it really should think how to improve its
>>> performance - not of generated programs, but of generation itself.
>>> If compilation of a trivial program on a pumpy hardware takes 5
>>> minutes and gigabytes of RAM and diskspace, few people will use it
>>> for other purposes beyond curiosity. There's something very
>>> un-Pythonic in waiting 5 mins just to run 10-line script. Type
>>> hints can help here too ;-) (by not wasting resources propagating
>>> types thru the same old standard library for example).
>>
>> Sorry, but that's nonsense. PyPy would be a seriously useless
>> interpreter if running a 10-line script required such a lengthy
>> compilation, so, obviously, that's not what happens.
>>
>> You seem to misunderstand what PyPy is: it's an interpreter with a
>> just-in-time compiler, not a static compiler. It doesn't generate
>> programs in any meaningful sense. Instead, it interprets the program,
>> and when it detects a hot code path, it compiles it to machine code
>> based on the precise types it sees. No resources are wasted on code
>> that isn't actually executed.
>
> Regardless of whether I understood that meta-meta stuff, I just
> followed couple of tutorials, each of them warning of memory and disk
> space issues, and both running long to get results. Everyone else
> following tutorials will get the same message I did - PyPy is a
> slow-to-work-with bloat.

Ah, I suppose you're talking about the RPython tool chain, which is used 
to build PyPy. Though it's an interesting topic in itself (and is pretty 
much comparable to Cython wrt. type hints), it has about as much 
relevance to PyPy users as the inner workings of GCC have to CPython users.

Well, the thing is that people don't seem to want to write PyPy 
tutorials, because it's boring. However, I can give you the definitive 
3-line version:
1. Download and install PyPy [http://pypy.org/download.html]
2. Launch the 'pypy' executable.
3. Go read https://docs.python.org/2/tutorial/

> As for uber-meta stuff PyPy offers - I'm glad that's all done in
> my favorite language, leaving all other languages behind. I'm saddened
> there's no mundane JIT or static compiler usable and accepted by all
> community - many other languages have that.
>
> This all goes pretty offtopic wrt to the original discussion, so again,
> what's your point - you say that all these things can't be done in
> Python, or there's no need for it to be done? That people should look
> somewhere else? I submitted a bug to jinja2 project and posted message
> on its mailing list - I didn't get reply for 3 months. Why? Because its
> maintainer went hacking another language, how was it called, alGOl, or
> something. You want me and other folks to go too? Sorry, I'm staying so
> far, and keep dreaming of better Python's future (where for example if
> I need to get more performance from existing app, I can gradually
> optimize it based on need, not rewrite it in another language or be
> hitting "not implemented" in uber-meta stuff).

"If you want your code magically to run faster, you should probably just 
use PyPy" - Guido van Rossum - 
https://www.youtube.com/watch?feature=player_detailpage&v=2wDvzy6Hgxg#t=1010