6 ms·

Amen. Python 3 has created an incredible amount of work in the aggregate for the authors of all the 2.X libraries that must be ported. Even worse, libraries tha

Amen. Python 3 has created an incredible amount of work in the aggregate for the authors of all the 2.X libraries that must be ported. Even worse, libraries that are no longer actively maintained must now be taken over by someone new and ported. All for new language features of very dubious value. If Python 3 brought us real threading with no GIL, that would be worth the pain. But instead, we get removal of a few warts and backward-incompatibility. One can only imagine how much damage the years of incompatibility and confusion caused by this decision have curtailed the popularity of the language. 2to3 is impressive and useful for implementating arbitrary code transformations, but obviously it can't magically make old code handle bytes/chars/unicode properly from a semantic standpoint. And think about how the 3.X changes totally screwed the Jython and PyPy (and Cython, and IronPython, and...) teams. We were headed towards much higher-performance implementations of the language, with additional powerful features like sandboxing and JIT, and it was set back years by the 3.X schism. Furthermore, the continued complication of the language makes it ever less likely that core problems like the GIL will ever be fixed. (Yes, I know Jython and IronPython are GIL-free.) My startup relies heavily on Python, and the only reason I don't seriously regret choosing Python as a core technology is that there was nothing else better at the time. The Python overlords have reduced the language to the best of bad options; it didn't have to be this way. FAIL. I still hope against hope that there will be a Python 4 that brings backward compatibility and GIL removal. But since none of the overlords seem to care about either of these goals, and since both get harder with every new Python 3 release, it's probably just my own sad little fantasy.

sho_hn 14y ago
> And think about how the 3.X changes totally screwed the Jython and PyPy (and Cython, and IronPython, and...) teams. We were headed towards much higher-performance implementations of the language, with additional powerful features like sandboxing and JIT, and it was set back years by the 3.X schism. I don't see how the 3.x changes have set back PyPy "by years". PyPy was focussing exclusively on 2.x until very recently, and made its last big steps towards production-readyness entirely undisturbed by the 3.x transition. As of a couple of months ago they now have a small team working on 3.x support, which has made huge progress in a short time frame and doesn't seem to have detracted from progress in the core and further 2.x release at all as far as I can see. > Furthermore, the continued complication of the language makes it ever less likely that core problems like the GIL will ever be fixed. Ironically, specifically the oh-so-handicapped PyPy is currently working on a new approach to address the GIL with their transactional memory work. And the language has gotten less complicated with 3.x, not more. > I still hope against hope that there will be a Python 4 that brings backward compatibility and GIL removal. But since none of the overlords seem to care about either of these goals [...] Right, that's why 3.3 just added back support for u'' for increased backwards compat and ease of porting. You're making a lot claims that simply seem to have no basis in reality.
- dmbaggett 14y ago
  The reality is self-evident from the PyPy home page: "PyPy is a fast, compliant alternative implementation of the Python language (2.7.2)." Why not 3.3? Oh, right, because when the PyPy team started, Python 2.X was the Python language. Now it's not. This has been the case (PyPy has existed and supported 2.X code) since 3.0 was released. I.e., for years. As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. Which, of course, is the whole point. But, yes! Thank goodness I can type u'...' again! That will save me years of work! FAIL.
  - sho_hn 14y ago
    > As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. This sort of comment doesn't really make me feel like you're qualified to comment on the subtleties of killing the GIL, to be honest. When it comes to removing the GIL, any form of "it's slower" is usually going to refer to single-threaded workloads, and avoiding to be slower for those is going to be nigh on impossible. The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. And really, it's at the proof of concept stage right now, hardly optimized. And there's new CPU hardware with hardware support for transactional memory coming down the pipe.
    - masklinn 14y ago
      > The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. This idea has been rejected by the core team though, getting rid of the gil with a major performance hit is not considered acceptable when most existing Python code is not significantly affected by the GIL.
      - sho_hn 14y ago
        Aye, which I think is reasonable, especially in the context of the GIL-removal approaches that were on the table at the time and the effort needed to implement them in CPython. I think the PyPy folks want to get to a place where you can run PyPy in modes tuned for either single-threaded or concurrent workloads.

sho_hn 14y ago

> And think about how the 3.X changes totally screwed the Jython and PyPy (and Cython, and IronPython, and...) teams. We were headed towards much higher-performance implementations of the language, with additional powerful features like sandboxing and JIT, and it was set back years by the 3.X schism. I don't see how the 3.x changes have set back PyPy "by years". PyPy was focussing exclusively on 2.x until very recently, and made its last big steps towards production-readyness entirely undisturbed by the 3.x transition. As of a couple of months ago they now have a small team working on 3.x support, which has made huge progress in a short time frame and doesn't seem to have detracted from progress in the core and further 2.x release at all as far as I can see. > Furthermore, the continued complication of the language makes it ever less likely that core problems like the GIL will ever be fixed. Ironically, specifically the oh-so-handicapped PyPy is currently working on a new approach to address the GIL with their transactional memory work. And the language has gotten less complicated with 3.x, not more. > I still hope against hope that there will be a Python 4 that brings backward compatibility and GIL removal. But since none of the overlords seem to care about either of these goals [...] Right, that's why 3.3 just added back support for u'' for increased backwards compat and ease of porting. You're making a lot claims that simply seem to have no basis in reality.

dmbaggett 14y ago
The reality is self-evident from the PyPy home page: "PyPy is a fast, compliant alternative implementation of the Python language (2.7.2)." Why not 3.3? Oh, right, because when the PyPy team started, Python 2.X was the Python language. Now it's not. This has been the case (PyPy has existed and supported 2.X code) since 3.0 was released. I.e., for years. As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. Which, of course, is the whole point. But, yes! Thank goodness I can type u'...' again! That will save me years of work! FAIL.
- sho_hn 14y ago
  > As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. This sort of comment doesn't really make me feel like you're qualified to comment on the subtleties of killing the GIL, to be honest. When it comes to removing the GIL, any form of "it's slower" is usually going to refer to single-threaded workloads, and avoiding to be slower for those is going to be nigh on impossible. The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. And really, it's at the proof of concept stage right now, hardly optimized. And there's new CPU hardware with hardware support for transactional memory coming down the pipe.
  - masklinn 14y ago
    > The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. This idea has been rejected by the core team though, getting rid of the gil with a major performance hit is not considered acceptable when most existing Python code is not significantly affected by the GIL.
    - sho_hn 14y ago
      Aye, which I think is reasonable, especially in the context of the GIL-removal approaches that were on the table at the time and the effort needed to implement them in CPython. I think the PyPy folks want to get to a place where you can run PyPy in modes tuned for either single-threaded or concurrent workloads.