4 ms·
There 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 un
by joconde 5y ago
There 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.