[Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Greg Ewinggreg.ewing at canterbury.ac.nz
Mon Mar 21 06:42:37 CET 2011


Guido van Rossum wrote: > Cython feels much less > mature than CPython; but the latter should only have dependencies that > themselves change even slower than CPython.  You might be slightly more amenable to Pyrex, then, which changes at a much more conservative pace! They appear superficially similar, but there is a difference in underlying philosophy. Pyrex makes no claim to be a Python compiler; rather, it's a tool for bridging between the Python and C worlds. As such, strict adherence to Python syntax and semantics, or supporting all Python features, or performing heroic optimisations on pure Python code, are not design goals. So it wouldn't make sense to try to compile any of the pure Python parts of the stdlib with Pyrex. However, it could make sense to use it for some of the modules currently written in C, or for future modules that would otherwise be written in C, to make them easier to write, read and maintain. Think of it as a tool for writing modules in C without having to worry about reference counts or exception handling. If you think you might seriously consider using Pyrex, I could translate a module or two from the stdlib so you can see how the code might look. > I also am unclear on how > exactly you're supporting the different semantics in Python 2 vs. 3 > without recompiling.  I gather that Cython generates code with a lot of #ifs for doing things differently depending on the Python version. I haven't decided exactly how to handle Python 3 in Pyrex yet, but I have some ideas. I'm not sure whether it will generate dual-version C files or not. It probably wouldn't matter much for stdlib usage, though, because it only needs to generate C code good enough for a particular release of Python. -- Greg 


More information about the Python-Dev mailing list
close