81–90 of 105 posts
Earlier quoted context omitted.
So why did you bring them up…
My words were > So it will join PyPy and GraalPy in the corner. If you cannot understand what that means, I am not a English professor.
Earlier quoted context omitted.
No, it’s a simple request to fully investigate the options before committing a massive piece of work to Python. We’ve seen bad implementations of things land before and now live forever. And frankly, if the team can’t pull together a strong maintenance plan, it can’t be allowed to remain in main.
> We’ve seen bad implementations of things land before and now live forever. Er, doesn't that depend on how leaky the abstraction is? How often have you seen a JITted language be unable to swap in a new JITter due to some sort of unintended coupling?
Earlier quoted context omitted.
No, it’s a simple request to fully investigate the options before committing a massive piece of work to Python. We’ve seen bad implementations of things land before and now live forever. And frankly, if the team can’t pull together a strong maintenance plan, it can’t be allowed to remain in main.
> and now live forever. What forever are you talking about? Python removes stuff every single release.
Earlier quoted context omitted.
My words were > So it will join PyPy and GraalPy in the corner. If you cannot understand what that means, I am not a English professor.
I understand your words, I don’t understand why you think they’re relevant to the discussion.
Earlier quoted context omitted.
I understand your words, I don’t understand why you think they’re relevant to the discussion.
Relegated to niche users, just like the other two.
Not even remotely the same context.
Earlier quoted context omitted.
15% faster on top of a base interpreter that itself got 40%-50% faster on the same timeframe.
Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it. Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.
It is nice to have the speed, always. But in Python, it would be a mistake to do it at the expense of flexibility. Same for typing: it is great to have it. I use it. But Python should be dynamic and the rest and extension that does not compromise everything else.
If a JIT can make Python 2 or 3x faster, or even 10x for some workloads, that is nice. But the language itself should support same idioms, reflection, dynamic typing, etc at the same level.
Earlier quoted context omitted.
> and now live forever. What forever are you talking about? Python removes stuff every single release.
Default list/dict arguments is the one that comes to mind. Yes, I know why it happens, no, it’s still bad because it trips up every beginner.
Earlier quoted context omitted.
Relegated to niche users, just like the other two.
Except it’s not. The intention of JIT in CPython is to make it into the main branch feature complete. If they can’t get the necessary support then it won’t be relegated to niche uses, it’ll be abandoned and need a new effort to get off the ground. Not even remotely the same context.
We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.
Earlier quoted context omitted.
Default list/dict arguments is the one that comes to mind. Yes, I know why it happens, no, it’s still bad because it trips up every beginner.
Why does it happen?