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

[Guido van Rossum]

On Mon, Mar 21, 2011 at 3:44 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 21.03.2011 11:58, schrieb Stefan Behnel:
>> [long post ahead, again]
>>
>> Guido van Rossum, 21.03.2011 03:46:
>>> Thanks for the clarifications. I now have a much better understanding
>>> of what Cython is. But I'm not sold. For one, your attitude about
>>> strict language compatibility worries me when it comes to the stdlib.
>>
>> Not sure what you mean exactly. Given our large user base, we do worry a
>> lot about things like backwards compatibility, for example.
>>
>> If you are referring to compatibility with Python, I don't think anyone
>> in the project really targets Cython as a a drop-in replacement for a
>> Python runtime. We aim to compile Python code, yes, and there's a
>> hand-wavy idea in the back of our head that we may want a plain Python
>> compatibility mode at some point that will disable several important
>> optimisations.
>
> I think that's the attitude Guido worries about: if you don't have the
> desire to provide 100% Python compatibility under all circumstances
> (i.e. including if someone passes parameters of "incorrect" types),
> then there is very little chance that we would replace a Python module
> with a Cython-compiled one.
>
> The only exception would be cases where the Python semantics is murky
> (e.g. where Jython or so actually behaves differently for the same
>  Python code, and still claims language conformance). E.g. the exact
> message on a TypeError might change when compiling with Cython,
> but the cases in which you get a TypeError must not change.

One other significant use case is the situation where we have an
optional replacement module written in C (e.g. heapqmodule.c vs.
heapq.py). There are usually many semantic differences between the C
and pure-python module that we don't care about (e.g. monkeypatching
won't work).

The size of Cython as a dependency and its development speed are still
problems though. In general for the core I don't think we want the
repo to contain generated code that can only be regenerated using a
3rd party dependency. (True, we have a few generated files, e.g.
configure; but in that case the generator -- autoconf --  is a
standard installed tool on Linux and is used by most open source
projects.)

Still, I think it would be great if someone tried something like this
for a specific stdlib module and came back with a story about the
experience, rather than having a theoretical discussion about possible
pros and cons.

-- 
--Guido van Rossum (python.org/~guido)