[Python-Dev] Python Language Summit at PyCon: Agenda (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sat Mar 2 17:58:18 CET 2013
- Previous message: [Python-Dev] Python Language Summit at PyCon: Agenda
- Next message: [Python-Dev] Python Language Summit at PyCon: Agenda
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Mar 1, 2013 at 7:41 PM, Stefan Behnel <stefan_ml at behnel.de> 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...)
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'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 (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)
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.
Yes, a CPython runtime summit some year would be interesting.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Python Language Summit at PyCon: Agenda
- Next message: [Python-Dev] Python Language Summit at PyCon: Agenda
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]