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

[Paul Sokolovsky]

Hello,

On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy <ronan.lamy at gmail.com> wrote:

> >>>> Also ask why no one used type specifier, they are possible since
> >>>> Python 3.0 ?
> >>>> Because it is the wrong way for Python.
> >>>
> >>> That's an example of how perceptions differ. In my list,
> >>> everyone(*) uses them - MyPy, MicroPython, etc. Even more should
> >>> use them (any JIT module, which are many), but sit in the bushes,
> >>> waiting for a kick, like PEP484 provides.
> >>
> >> It's OK that type hints are only to assist the programmer.
> >
> > Yes, it's OK to have a situation where type hints assist only a
> > programmer. It's not OK to think that type hints may be useful only
> > for programmer, instead of bunch more purposes, several of which
> > were already shown in the long previous discussion.
> >
> >> 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 ?

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

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


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com