[Python-Dev] 2.4 news reaches interesting places

[Glyph Lefkowitz]

On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:

> The only thing that will fix the PR issue is to have a Python compiler 
> distributed as part of the language.  It doesn't matter if it doesn't 
> support the full generality of Python, or even if it doesn't speed many 
> operations up much.  The only real requirements are that it can be used to 
> produce "native" executables, and that it be an official part of the 
> language, not a separately-distributed tool like Psyco or Pyrex.  Then, it 
> will perhaps be a sufficient "security blanket" to stop people FUDding 
> about it.

I am aware that Pyrex is still in flux, so perhaps it is too soon to
propose this even for 2.5, but I think it's worth bringing up anyway: I
would like Pyrex to be distributed with the Python core.  I agree that
it should be modified to produce full .exe files and not just .dlls on
Windows, but many potential users *are* seriously concerned about
efficiency and not just simplifying distribution.

The main benefit would be imparting a Pythonesque flavor to optimized
code.  The thing which experienced Python-ers say is, technically,
correct: "If you need speed, rewrite the hot-spots in C.".  To someone
already steeped in the Python way, this means, "write your application
in Python, do your architecture in Python, profile it, and write the 300
lines or so of your 25000 line application that are *really*
speed-critical in a faster language".  There are a few, very very
specialized areas where this approach is not the best one, but
unfortunately C programmers do not hear this when you say it.

What they hear is, "If speed is important to your application, write it
in C, and only write the parts where you need flexibility in Python.
They will all be deadly slow.  If you notice that they are slow, you are
going to have to rewrite them in C anyway."  To wit, Python is only
interesting to the people who are going to "script" your application.

Although writing code in Pyrex ends up being a technically similar
solution, politically it is radically different.  If the Python-expert's
answer were instead, "write the slow parts in Pyrex", then the C
programmer's plan changes - instead of writing in C, because they know
they are going to need to rewrite all the slow parts anyway, they
realize that there is an explicitly Python way to rewrite the slow
parts, that may leverage SOME of their existing C knowledge.  They learn
Python and appreciate Python secure in the knowledge that this effort
will not be wasted.

Finally, there are real benefits to Pyrex when making the transition
between levels in your optimized code.  All the common areas for
mistakes when interfacing with Python - missing refcounts when getting,
changing, or deleting attributes, calling Python callbacks, and using
basic Python data structures - are all taken care of so that the dive
into C is far less abrupt.  The people this PR is geared to are those
who would write in C because of efficiency concerns, so they would
likely be looking at Pyrex before choosing to start a large project, and
the simple code examples would be both familiar enough (hey, that's a 32
bit integer!  I remember that!) but also different enough (wow, you can
just call a script with "foo()"?) that they would be impressed.