An announcement from the Steering Council regarding the JIT project

29 points by sanxiyn


rtpg

I don't think this looks super acrimonious but it does feel a bit awkward. the JIT is this experimental feature so I don't see issues with merges continuing.

Surely if people like Shannon say "we'll get a PEP to you but please let us avoid awkward bitrop" I feel like their word is good enough to avoid placing a hard lock on further movement.

Maybe this public announcement is after some private conversation. But I hope that this can go smoothly without causing unnecessary pain

olliej

The suggestion for an interface to allow different jit implementations demonstrates a deep misunderstanding of what is necessary for high performance JITs - the folk working on the JIT had a number of problems but a big one is that it seems like they weren’t able/willing to make significant changes to the core runtime data structures (obviously there are issues where Python basically exposed its entire implementation as the API as well), but you can just make types get rewritten if people do do bad things - but again it requires a community where performance really matters.

Python has historically gotten by on any library that needs performance not being written in Python, and that impacts priorities (I recall language performance shoot outs that we’re comparing something like a basic implementation of an algorithm, to a Python implementation that was literally just wrapping a well developed high performance implementation provided by a c library)

alexjurkiewicz

I wonder why this was posted as a public announcement, rather than a private request to core jit developers.

icefox

I feel like an anthropologist somewhere needs to write a book on the bureaucracy of open-source software projects, and Python (as well as Debian) should be a key study point. This isn't a slam; this sort of bureaucracy is in the end a distributed decision-making/consensus-reaching process, and making it work well at such a large scale is difficult.