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

[Robert Bradshaw]

On Wed, Mar 23, 2011 at 12:45 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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 started a list at http://wiki.cython.org/Unsupported . I'd say we
can be as compatible as Jython/IronPython is, and more than CPython is
between minor versions. I would be happy with a short, well-justified
list of differences. This will be clearer once the community (which
we're a part of) defines what Python vs. implementation details means.

> 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.

We have multiple inheritance for normal classes, so that's covered.
Any auto-cdeffing of classes would have to be done carefully.

>> 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.

+1

- Robert