4 ms·
Ugh. Python could be fast, but the python core team / GvR put so many ridiculous constraints on what can change that maybe at best it gets like 10% faster, some
by overgard 5y ago
Ugh. Python could be fast, but the python core team / GvR put so many ridiculous constraints on what can change that maybe at best it gets like 10% faster, some day. Anything meaningful means breaking compatibility with extensions, and they absolutely won't do that. I feel like GvR got burned in the python 2->3 transition, but he learned the wrong lesson. The lesson he seemed to learn was never break compatibility but what he should have learned is don't break compatibility for stupid things nobody cares about. Making the interpreter much faster is something people would care about, but they'll never modify it in any meaningful way nor will they ever endorse something like PyPy.
- Joker_vD 5y agoThe interpreter that breaks the backward compatibility makes that code run infinitely slower (i.e. it does not run at all) instead of running faster. And it doesn't matter if the compatibility was broken for some thing you actually care about: if your code can't run at all until the broken third-party dependency is fixed by its maintainer, you simply won't upgrade, will you?
- overgard 5y agoI work in the Node ecosystem, and while they break compatibility every once in a while I can't say I've ever even really noticed. There's a way to do it without it being a catastrophy.
- joconde 5y agoThere is no way I'm doing anything serious in a language that decides to make us rewrite part of our work regularly. We have actual work to do... I think you underestimate how important stability is.
- overgard 5y agoNot really suggesting any amount of rewriting of python code, just that extensions might need to be recompiled and/or not depend on reaching into internals they shouldn't touch. To users it should mostly be invisible.
- joconde 5y ago> extensions might need to [...] not depend on reaching into internals they shouldn't touch Is that the problem? I thought I read somewhere that the C/C++ extension API would have to be broken to allow for removing the GIL, for example. The API, not just internals that shouldn't be touched by user code. If it were only a rebuild, I don't think anyone would object; pip packages are built once per Python version anyway. Breaking the API would be a different story for libraries that make heavy use of C++ extensions.
- rich_sasha 5y agoI was thinking the same until I had to do the change. It was surprisingly easy. And I had a lot of poorly tested code to port.
- Redoubts 5y agoWhat if your language got 100x faster? What if deployment became trivial? Would that be incentive enough? I would take annoying breakages for that.
- joconde 5y agoI'd be happy to make the decision myself. I wouldn't be happy if I learned on HN that I have N years to re-write X% of our production code before our language stops being supported.
- uyt 5y ago> nor will they ever endorse something like PyPy What's their beef with PyPy?
- overgard 5y agoAs far as I can tell, it's because it's not based on CPython. For whatever reason, to GvR Python == CPython, other interpreters don't matter. It's a shame, because python the language is fine, but CPython the interpreter is janky and slow.
- rich_sasha 5y agoPyPy is a trade off and not universally better. It has a larger memory footprint (already a bit of an issue for Python), higher startup times and incomplete compatibility, in particular with C compiled libs used precisely where performance matters.