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.