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

[Stefan Behnel]

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