[Cython] PyCon-DE wrap-up by Kay Hayen

[mark florisson]

On 9 October 2011 18:35, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> Kay Hayen wrote a blog post about his view of the first PyCon-DE, including
> a bit on the discussions I had with him about Nuitka.
>
> http://www.nuitka.net/blog/2011/10/pycon-de-2011-my-report/
>
> It was interesting to see that Nuitka actually comes from the other side,
> meaning that it tries to be a pure Python compiler, but should at some point
> start to support (Python) type hints for the compiler. Cython made static
> types a language feature from the very beginning and is now fixing up the
> Python compatibility. So both systems will eventually become rather similar
> in what they achieve, with Cython being essentially a superset of the
> feature set of Nuitka due to its additional focus on talking to external
> libraries efficiently and supporting things like parallel loops or the
> PEP-3118 buffer interface.
>
> One of the impressions I took out of the technical discussions with Kay is
> that there isn't really a good reason why Cython should refuse to duplicate
> some of the inner mechanics of CPython for optimisation purposes. Nuitka
> appears to be somewhat more aggressive here, partly because Kay doesn't
> currently care all that much about portability (e.g. to Python 3).

Interesting. What kind of (significant) optimizations could be made by
duplicating code? Do you want to duplicate entire functions or do you
want to inline parts of those?

I actually think we should not get too tied to CPython, e.g. what if
PyPy gets a CPython compatible API, or possibly a subset like PEP 384?

> I was previously very opposed to that (you may remember my opposition to the
> list.pop() optimisation), but now I think that we have to fix up the
> generated code for each new major CPython release anyway, so it won't make a
> difference if we have to rework some more of the code because a bit of those
> inner workings changed. They sure won't change for released CPython versions
> anymore, and many implementation details are unlikely enough to change for
> years to come. It's good to continue to be considerate about such changes,
> but some of them may well bring another serious bit of performance without
> introducing real portability risks. Changes like the Unicode string
> restructuring in PEP-393 show that even relying on official and long
> standing parts of the C-API isn't enough to guarantee that code still works
> as expected in new releases, so we may just as well start digging deeper.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>