[Python-Dev] Python Language Summit at PyCon: Agenda

Stefan Behnel stefan_ml at behnel.de
Fri Mar 1 10:41:00 CET 2013

Michael Foord, 27.02.2013 17:51:
> PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so.
> The agenda of topics for discussion so far includes the following:
> * A report on pypy status - Maciej and Armin
> * Jython and IronPython status reports - Dino / Frank 
> * Packaging (Doug Hellmann and Monty Taylor at least)
> * Cleaning up interpreter initialisation (both in hopes of finding areas
>   to rationalise and hence speed things up, as well as making things
>   more embedding friendly). Nick Coghlan
> * Adding new async capabilities to the standard library (Guido)
> * cffi and the standard library - Maciej
> * flufl.enum and the standard library - Barry Warsaw
> * The argument clinic - Larry Hastings


as in the years before, none of the Cython developers is attending the
PyCon-US, so we won't appear that the language summit either. It's a bit
sad that it always takes place at that venue, but I guess there'll just
always be people that can't come to one meeting or the other, so PyCon-US
would just catch the majority. I think it would still be interesting for
many of the attendants to get a status report about Cython, as there seems
to be some confusion and incomplete knowledge about what Cython actually
is, what we have achieved and where we are heading. But maybe the confusion
is large enough to require more than just a little status report to clear
it up.

It's also true that many of the topics above aren't really interesting for
us, because we just inherit them with CPython, e.g. stdlib changes.
Packaging is only relevant as far as it impacts the distribution of binary
extensions, and the main changes appear to be outside of that area (which
doesn't mean it's not truly wonderful that they are happening, Python
packaging has seen a lot of great improvements during the last years and
I'm very happy to see it getting even better).

Interpreter initialisation would be interesting and Cython could
potentially help in some spots here by making code easier to maintain and
optimise, for example. We've had this discussion for the importlib
bootstrapping and I'm sure there's more that could be done. It's sad to see
so much C-level work go into areas that really don't need to be that low-level.

I'm not so happy with the argument clinic, but that's certainly also
because I'm biased. I've written the argument unpacking code for Cython
some years ago, so it's not surprising that I'm quite happy with that and
fail to see the need for a totally new DSL *and* a totally new
implementation, especially with its mapping to the slowish ParseTuple*()
C-API functions. I've also not seen a good argument why the existing Py3
function signatures can't do what the proposed DSL tries to achieve. They'd
at least make it clear that the intention is to make things more
Python-like, and would at the same time provide the documentation.

The topics that would be interesting for us sound more like they'd benefit
from a "CPython runtime summit". I really think that it would be beneficial
for the CPython developers to learn how we solved problems that they have
on their lists or might at least run into in a couple of years, and for us
to see if we can't come up with cleaner solutions for problems that CPython
currently makes hard to do outside of the core. For example, making
C-implemented code Python compatible is actually not trivial and has cost
us a lot of investment. Nowadays, CPython is actually further away from
that in some areas than Cython, and I don't think it needs to stay that
way. It could certainly help both Cython and CPython if CPython gained some
of the capabilities for itself that we had to implement ourselves in clean
or hacky ways, but always outside of the core. There isn't really a reason
why C-implemented parts of CPython must behave all that different from
Python implemented parts, why modules must have a different API than other
objects, why builtins can't accept keyword arguments, ... These things just
get in the way once their camouflage as features is blown up.

Another topic is C-level calling between extensions that only see each
other through the CPython core. Python call semantics are nice, but also
extremely slow compared to C calls. Capsules are simple but slow and
static. Implementing a dynamic C calling interface between extensions with
a safe way to pass C signatures around and validate them (or adapt to them)
on the other side would be much easier with CPython support built into its
C function type than trying to do this outside of the core. And there's a
huge area of applications for such a feature, especially with the
increasing number of tools that do dynamic code generation on the CPython
platform. Eventually, this might also become interesting for non-CPythons,
as it might provide a way to interface efficiently with CPython extensions.

So, have fun at the language summit everyone, I'm looking forward to
skipping through the writeup. And I'd really like to see a CPython summit
happen at some point. There's so much interesting stuff going on in that
area that it's worth getting some people together to move these things forward.


More information about the Python-Dev mailing list