[Python-Dev] 2.4 news reaches interesting places (original) (raw)

Glyph Lefkowitz glyph at divmod.com
Thu Dec 9 22:11:33 CET 2004

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.

More information about the Python-Dev mailing list