Re: Questions about your approach
Greg Ewing <[email protected]>
| Newsgroups | gmane.comp.python.pyrex |
|---|---|
| Message-ID | <[email protected]> |
Paul Biggar wrote: > Did pyrex originally compile standard python, or was it annotated with > types from the start? It had type declarations from the start. It was conceived as a bridge between Python and C, with automatic conversion between Python and C data wherever it was obvious what needed to be done. For that, I needed information about the C types. > Has you run benchmarks on the compiled applications? Not very much. I once timed the primes.pyx example as about 100 times faster than a Python version of the same thing. I created a Pyrex version of my Plex scanner, and managed to get it to scan about 30 times faster. However, speed isn't really the main point of Pyrex -- the point is to interface between Python and C, either external or written in the C-subset of Pyrex. The C parts run about as fast as you would expect if they were written in straight C, which isn't very surprising. The Python parts don't need to be particularly fast, as they're only intended for getting the data in and out of a form that the C parts can use. > Are there any papers describing python? You mean Pyrex? Not currently. > I wonder if you have any comments on your approach vs. that of the > defunct python2c? They're aimed at different problems, I think. Python2c seems to have been an attempt to compile pure Python code. Pyrex is for interfacing between Python and C, so it's competing more with the likes of SWIG and Boost Python. It happens to have much the same effect as python2c if you apply it to pure Python code, but that's pretty much accidental. -- Greg