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

[Kevin Modzelewski]

On Fri, Apr 24, 2015 at 6:05 PM, Ronan Lamy <ronan.lamy at gmail.com> wrote:

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


I'm with the PyPy folks here -- I don't see any use for PEP 484 type hints
from a code generation perspective.  Even if the hints were guaranteed to
be correct, the PEP 484 type system doesn't follow substitutability.  I
don't mean that as a critique, I think it's a decision that makes it more
useful by keeping it in line with the majority of type usage in Python, but
it means that even if the hints are correct they don't really end up
providing any guarantees to the JIT.


>
>
>  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
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/kmod%40dropbox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150424/ec81d872/attachment.html>