Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python JIT project was asked to pause development

discuss.python.org

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Python JIT project was asked to pause development

#51

Post by sitkack »

woodruffw wrote: post #49
sitkack wrote: post #48

I have used Python as my main language since the late 90s and it has been over the last decade and half been getting more unserious. It would be nice if cpython opened up a bit, pluggable GC and JIT would go along way towards reducing this manufactured drama. It wasn't cool to see PyPy or Stackless getting sidelined.

This isn't really a substantive comment, and to at least one extent it's trivially falsifiable (15 years is before Python 3 became usable, so that alone is a "serious" change in the language). > pluggable GC and JIT would go along way One of the points mentioned in the linked discussion is explicitly about ensuring that the JIT design enables multiple implementations.

Python 2 to 3 transition was also unserious.

The flippant attitude of cpythons wrt the standard library is also unfortunate.

Please with your substantive comment comment.

Re: Python JIT project was asked to pause development

#52

Post by elpocko »

nmstoker wrote: post #35
elpocko wrote: post #7

Earlier quoted context omitted.

Don't bother clicking, that post got 0 attention. Not helpful, mate.

It is literally the same link, it was the original and it had the correct title rather than the editorialised one here. At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.

It would make sense if there was any activity on that older post. A 12 hour old post with no comments is dead, linking to it is a waste of time, especially for those who click on it to find 0 comments.

I did click on your link, it was a waste of time and that wasn't very nice.

Re: Python JIT project was asked to pause development

#53

Post by KaiserPro »

jhayward wrote: post #8

> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. If I were a contributor I would read such language as saying "we have no respect for you or your intelligence, so we'll just straight up gaslight you and expect you to accept it." The dictum can't be read literally - it has to be read like the manipulative, narcissist-spe…

> The dictum can't be read literally

out of curiosity, why not?

I mean it seems like they want to get a full spec of what JIT should look like in main? given the faff that hapened with the GC removal, I can sort see why they'd want to do this properly. Especially now that it seems like its practical.

Re: Python JIT project was asked to pause development

#54

Post by woodruffw »

sitkack wrote: post #51
woodruffw wrote: post #49

Earlier quoted context omitted.

This isn't really a substantive comment, and to at least one extent it's trivially falsifiable (15 years is before Python 3 became usable, so that alone is a "serious" change in the language). > pluggable GC and JIT would go along way One of the points mentioned in the linked discussion is explicitly about ensuring that the JIT design enables multiple implementations.

Python 2 to 3 transition was also unserious. The flippant attitude of cpythons wrt the standard library is also unfortunate. Please with your substantive comment comment.

It seems to have been serious enough; I don't think Python would have succeeded as a language if they hadn't done Python 3.

> Please with your substantive comment comment.

I think binning things as drama isn't substantive, particularly when noting about the linked conversation seems dramatic. I also think they're actually talking about the thing you want (pluggable JIT), so the objection seems incongruous.

Re: Python JIT project was asked to pause development

#55

Post by pjmlp »

scott_w wrote: post #47
pjmlp wrote: post #41

Earlier quoted context omitted.

So it will join PyPy and GraalPy in the corner. Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.

JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing. If they can't get a PEP accepted within 6 months then it's best that the code isn't weighing on the main codebase until an approach can be agreed, at which point work integrating it into main can restart. It's not an all-or-nothing situation.

> JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing.

I haven't said otherwise.

Re: Python JIT project was asked to pause development

#56

Post by baq »

wavemode wrote: post #36
mellosouls wrote: post #32

Editorialised title. Development hasn't been paused (with negative implications). It's now considered significant enough that they've requested feature freeze in CPython main until governance/process questions are settled.

It's effectively a pause. In a project the size of CPython, and a subproject the complexity of a JIT, you can't continue work on a separate branch/repo without guaranteeing that there will be a massive amount of (both textual and semantic) merge conflicts down the road.

Nah, you just merge main back every day or so.

Re: Python JIT project was asked to pause development

#57

Post by [deleted] »

simonw wrote: post #25
OutOfHere wrote: post #6

Losing development momentum for a beancounting reason like this one is a sure way to kill a project. It works every time. Once development is halted, it is very difficult to pick it back up.

They're not being asked to halt development, they're being asked to halt landing new features on the cPython main branch.

[deleted]

Re: Python JIT project was asked to pause development

#58

Post by zem »

_old_dude_ wrote: post #12
jhayward wrote: post #8

> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. If I were a contributor I would read such language as saying "we have no respect for you or your intelligence, so we'll just straight up gaslight you and expect you to accept it." The dictum can't be read literally - it has to be read like the manipulative, narcissist-spe…

I agree. And the next section is very clear that they want to kill the project. > For example, rather than proposing one single concrete JIT implementation, > it may make more sense for the PEP to describe a JIT infrastructure that > can support multiple implementation strategies. > Since many different and promising JIT tracing approaches continue to be proposed, > we believe the infrastructure should make it easy t…

I'm a big fan of the pluggable jit strategy (I even gave a brief presentation about it at an earlier pycon). the idea is that you identify the seams in the interpreter where the jit interacts with the main interpreter loop, and then provide a clean mechanism for the built-in jit to be replaced by something else that works with the same api surface. it's a bit harder than letting the built-in jit be tightly coupled to and intertwined with the rest of the interpreter but certainly not far harder, and the work to get this sort of clean separation will help keep the jit maintainable even if there is never a second jit.

Re: Python JIT project was asked to pause development

#59

Post by Retr0id »

wavemode wrote: post #37
oefrha wrote: post #27

Sounds reasonable given the recent YOLO GC debacle https://discuss.python.org/t/reverting-the-incremental-gc-in... .

That seems entirely unrelated?

It's related in the sense that it's an example of something that didn't go through the formal PEP process

Re: Python JIT project was asked to pause development

#60

Post by sidewndr46 »

mwkaufma wrote: post #26

>> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. lol >> For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies. poison-pill requirement >> We are setting a window of six months for…

Without a doubt, a great way to kill any project is to add unrelated and ambitious technical requirements to the project. This opens it up to an avalanche of discussion and feedback and almost certainly will kill it off
Post reply on HN