[Python-Dev] Python Language Summit at PyCon: Agenda (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Sat Mar 2 19:30:21 CET 2013

Hi Nick,

thanks for the feedback.

Nick Coghlan, 02.03.2013 17:58:

On Fri, Mar 1, 2013 at 7:41 PM, Stefan Behnel wrote:

Michael Foord, 27.02.2013 17:51: 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). I'm puzzled by this one. Did you leave out PEP 427 (the wheel format), because it's already approved, and hence not likely to be discussed much at the summit, or because you don't consider it to impact the distribution of binary extensions (which would be rather odd, given the nature of the PEP and the wheel format...)

I admit that the wheel format has been sailing mostly below my radar (I guess much of the discussion about it is buried somewhere in the distutils SIG archives?), but the last time it started blinking brightly enough to have me take a look at the PEP, I didn't really see anything that was relevant enough to Cython to pay much attention or even comment on it. As I understand it, it's almost exclusively about naming and metadata. Cython compiled extensions are in no way different from plain C extensions wrt packaging. What works for those will work for Cython just fine.

Does it imply any changes in the build system that I should be aware of? Cython usually just runs as a preprocessor for distutils extensions, before even calling into setup(). The rest is just a plain old distutils extension build.

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. Cython's notion of embedding is the exact opposite of CPython's, so I'm not at all clear on how Cython could help with PEP 432 at all.

I wasn't thinking about embedding CPython in a Cython compiled program. That would appear like a rather strange setup here.

In the context of importlib, I proposed compiling init time Python code into statically linked extension modules in order to speed it up and make it independent of the parser and interpreter, as an alternative to freezing it (which requires a working VM already and implies interpretation overhead). I agree that Cython can't help in most of the early low-level runtime bootstrap process, but once a minimum runtime is available, the more high-level parts of the initialisation could be done in compiled Python code, which other implementations might be able to reuse.

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. That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic

I'll happily provide my feedback to that approach. It might also have a positive impact on the usage of Py3 argument annotations, which I think merit some more visibility and "useful use cases".

(especially given Guido's expressed tolerance for the idea of "/" as a possible marker to indicate that the preceding parameters only support positional arguments - that was in the context of Python discussion where it was eventually deemed "not necessary", but becomes interesting again in a C API signature discussion)

I've not really had that need myself yet, but I remember thinking of it at least once while writing Cython's argument unpacking code. I think it would get rid of a currently existing asymmetry between positional arguments and keyword(-only) arguments, and would remove the risk of naming collisions with positional arguments, most notably when **kwargs is used. And yes, I agree that it would be most interesting for C signatures, just like kwonly arguments are really handy there. It might not be all too hard to write up a prototype in Cython. And I should be able to find a couple of places in lxml where I could use this as an actual feature, so I might actually give it a try when I find the time.

Stefan

More information about the Python-Dev mailing list