[Cython] Rewriting/compiling parts of CPython's stdlib in Cython

Stefan Behnel stefan_ml at behnel.de
Wed Mar 23 08:45:01 CET 2011

Craig Citro, 23.03.2011 08:11:
>> We have a clear 1.0 goal, being able to compile the full Python
>> language. We're not there yet, but very close. It may make sense at
>> that point to also clean up any cruft we don't want to continue
>> supporting forever. I agree, until that point, there's no way we would
>> be a Python development dependency.
> Are we aiming for 100% compatibility, or 99.9%? For instance, I seem to
> recall a few dark corners we aren't planning on covering

I think it's more like 98%. CPython, PyPy and friends consider the more 
obscure features like frame access a core Python language feature, but I 
don't see an interest in making that work in Cython. If someone wants to 
write the code, fine, as long as it's switched off outside of a future 
"strict compatibility mode". I've never seen this used in any code that I 
would have wanted to compile with Cython, and even in Python code it's only 
really used for more or less "clever hacks".

> maybe some details of traceback construction?

What I would like to see here is simply a fallback of the frames that we 
create for tracebacks to look for a .py file (or even .pyx/.pxi file) next 
to the compiled .so file, so that they can print the source line for the 
executed line in the .so.

Apart from that, it boils down to the issue of frame construction. See 
above. Keep in mind that CPython's own C code currently gives you no frames 
at all, so Cython modules already have a serious advantage over what's 
there today.

> (I want to say multiple inheritance, too,
> but I think that's only an issue for cdef classes, right?)

Yes. That's how things work in CPython at the C level, and I'm fine with that.

> I think it would
> be good to have this written down -- in particular, it seems like there's
> some momentum right now for clearly delineating "Python language semantics"
> vs. "CPython implementation detail" in the python-devel community, so it
> might be a particularly good time to raise these questions.

+1, a "where do we stand?" topic is planned for the workshop anyway.


More information about the cython-devel mailing list