[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)

Kevin Modzelewski kmod at dropbox.com
Sat Apr 25 04:15:42 CEST 2015

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=playerdetailpage&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>

More information about the Python-Dev mailing list