On Mon, Mar 21, 2011 at 3:44 PM, "Martin v. Löwis" <mar...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
