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

[Stefan Behnel]

"Martin v. Löwis", 21.03.2011 23:44:
> Am 21.03.2011 11:58, schrieb Stefan Behnel:
>> 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.

We are aware of potential differences and generally consider (most of) them 
bugs. We even try to keep our exception messages in line with CPython 
(usually py3k, CPython has changed its own messages quite a bit during its 
lifetime, as our doctests can tell), and try to make optimised code as safe 
as possible by default. For example, we automatically raise TypeErrors on 
invalid arguments *iff* there is a user declared type for them, and we 
raise OverflowErrors during C type conversions and even some C calculations 
unless explicitly disabled by the user. If in doubt, we always try to copy 
CPython's own behaviour.

So it's almost always up to the user to explicitly divert from normal 
Python behaviour for performance reasons. And Cython's type driven code 
adaptations allow for a *very* broad range of explicit diversions that 
users can deploy in order to balance the user visible impact with the 
performance requirements.

Stefan