3 ms·

I hope everyone learned that breaking compatibility for the sake of fixing syntax (amongst other things) just isn't worth it. I'm happy that Python seems to be

I hope everyone learned that breaking compatibility for the sake of fixing syntax (amongst other things) just isn't worth it. I'm happy that Python seems to be finally pulling through this, but a lot of us are still stuck in 2.x land. I really wish Python 3 had been about concurrency and making it a part of the core of the language. There are over a dozen different python concurrency packages out there and most of them are pretty different from each other. It's confusing as all get out, and we end up religious wars over which one to use.

dangoldin 12y ago
Agreed - I really enjoy writing Python but the more I use it the more I run into concurrency and performance bottlenecks. I think the big win will be moving away from the GIL but I image that to be a big ordeal.
- freyrs3 12y ago
  If the core developers have committed to remaining C-ABI compatible with py3 until 2023 then there's basically no way anyone could fix the GIL. It would mean breaking ABI compatibility on the garbage collector and the interpreter. I find this aspect of the proposal kind of disturbing since it effectively prevents anyone from even trying to solve concurrency problems in mainline CPython for another decade.
- dragonwriter 12y ago
  GIL isn't so much a language issue as an implementation issue, and (as is the case with Ruby and MRI's GVL), I expect that the solution will be found in an alternative implementation (which may later become the mainline implementation), rather than an update to CPython. In Python's case, my guess would be that PyPy will be the the implementation that makes this mainstream.
m0th87 12y ago
Python 3 did address concurrency with the asyncio package. What it hasn't addressed is parallelism.
- Patrick_Devine 12y ago
  Asyncio wasn't added until 3.4, so it was hardly the initial thrust of what Python 3k was trying to accomplish. Guido even admits he didn't even understand how Twisted's Deferred's worked until a year ago: https://groups.google.com/forum/#!topic/python-tulip/ut4vTG-08k8 https://groups.google.com/forum/#!topic/python-tulip/ut4vTG-... ... which I think is great that he really took the time and Pep 3156 is the better for it. I still feel like this should have been what Py3K was about though, and not tightening up semantics in the language. Who cares about the semantics? Python has warts but we love it anyway.

dangoldin 12y ago

Agreed - I really enjoy writing Python but the more I use it the more I run into concurrency and performance bottlenecks. I think the big win will be moving away from the GIL but I image that to be a big ordeal.

freyrs3 12y ago
If the core developers have committed to remaining C-ABI compatible with py3 until 2023 then there's basically no way anyone could fix the GIL. It would mean breaking ABI compatibility on the garbage collector and the interpreter. I find this aspect of the proposal kind of disturbing since it effectively prevents anyone from even trying to solve concurrency problems in mainline CPython for another decade.
dragonwriter 12y ago
GIL isn't so much a language issue as an implementation issue, and (as is the case with Ruby and MRI's GVL), I expect that the solution will be found in an alternative implementation (which may later become the mainline implementation), rather than an update to CPython. In Python's case, my guess would be that PyPy will be the the implementation that makes this mainstream.

m0th87 12y ago

Python 3 did address concurrency with the asyncio package. What it hasn't addressed is parallelism.

Patrick_Devine 12y ago
Asyncio wasn't added until 3.4, so it was hardly the initial thrust of what Python 3k was trying to accomplish. Guido even admits he didn't even understand how Twisted's Deferred's worked until a year ago: https://groups.google.com/forum/#!topic/python-tulip/ut4vTG-08k8 https://groups.google.com/forum/#!topic/python-tulip/ut4vTG-... ... which I think is great that he really took the time and Pep 3156 is the better for it. I still feel like this should have been what Py3K was about though, and not tightening up semantics in the language. Who cares about the semantics? Python has warts but we love it anyway.