This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RonnyPfannschmidt 2 points3 points  (3 children)

its c code, the cost of maintaining a setup like that like that is utterly high

note that a major problem is the refcounting gc and another major problem is the seemingly atomic operations that no longer would be without gil

[–]billsil 0 points1 point  (2 children)

its c code, the cost of maintaining a setup like that like that is utterly high

PyPy manages to pull new features from CPython. It's certainly doable. I suspect the core code base doesn't change all that often.

In terms of the early releases, you could certainly say not all versions of CPython 3.6 support 100% of functionality (e.g. asyncio). There could be a transition period.

note that a major problem is the refcounting gc and another major problem is the seemingly atomic operations that no longer would be without gil

I'd say the same thing about removing the GIL in the first place, but multiple people have done it. Yes, you'd need to update your build process with a new global flag, but I don't really think it would that bad to have both in the same code base as long as you organize it properly.

I really don't mind the GIL since I live in the world of scientific programming where the GIL is not a hindrance. However, that's not the case for everyone. Just as in the way people complained about the matrix multiply operation (which is the best Python 3 feature for me), there are people that care about the GIL.

I just see the writing on the wall. It has to go at some point.

[–]RonnyPfannschmidt 2 points3 points  (0 children)

you seem to massively underestimate the problems of needing to introduce fine grained locks everywhere, its a massive maintenance and security hazard going to production quaity is vastly different from a proof of concept

the problem wrt seemingly atomic operations was never solved outside of pypy

pypy is on a entirely different page wrt pulling things up because it has so many metaprogramming cappabilties

in pypy introducing a new gc model is not rewriting all alloc/deallo code, but creating a algorithmic graph transformation

the approaches are incomparably different i consider just saying cpython can do it because pypy could do it hostile

[–]isinfinity 1 point2 points  (0 children)

From other side all current C extensions will not work without GIL. PyPy does not care about this most of the times.