5 ms·

Why on earth would PyPy be included? If GIL-Removal, PyPy, pip and virtualenv being included is your "must have" list, you're going to be waiting long after eve

by jnoller 16y ago

Why on earth would PyPy be included? If GIL-Removal, PyPy, pip and virtualenv being included is your "must have" list, you're going to be waiting long after everyone else has moved onward :) For me, it's simply "I just need my dependencies" - which is a simple statement, but an incredibly hard problem.

cdavid 16y ago
I think the problem is that python 3 is just different, without much improvements over 2 for many people. For example, the things which IMO were worth fixing at backward incompatibility price (like the import system, improved C API with ABI across minor versions, packaging) were not fixed. I have (in small parts) contributed to the python 3 conversion for numpy/scipy, and the only reason why I have done so is to be a good "python citizen", and because numpy is a major library in the python ecosystem. But I don't see any advantage in doing so. The cost is high, and the advantages near inexistent for me
- jnoller 16y ago
  You see - the reason your hit list of itches were not fixed were because no one stepped in to do them - this isn't anyones fault, but it doesn't mean important things were not fixed. Instead, the other itches (such as bytes vs. strings/unicode) were fixed. Function annotations, the standard library cleanup, and other things came along for the really big ride, which was the bytes/unicode/etc ride. So, there's lots of improvements that came with 3.0 - but the nice thing is is that it continues to evolve. We now have a New (more rational) GIL, we're probably going to have a futures package (http://www.python.org/dev/peps/pep-3148/ http://www.python.org/dev/peps/pep-3148/) and so on (heck, python3 is also getting a jit). And things will continue to be added. Everyone knows and admits that the transition will take years, but now with 2.x being "done" (meaning, no more releases past 2.7) and more great work being done in 3.x, hopefully people in general will start to see the benefits.
nailer 16y ago
Personally I don't know anyone who's running on 3.0 yet - so I think it will be a while before I get left behind.
- jnoller 16y ago
  And that was always the plan. 3.0 adoption was supposed to take several years. So it's all good - the big thing which needs to occur before most people will is some of the big libs need to port over.
  - nailer 16y ago
    I also have the sneaking suspicion some of the cool VM work will end up being there around the same time (that said, I really like the Queue and Thread objects in 2.6 for most purposes, despite all the complaints people make about the GIL).
    - jnoller 16y ago
      Eh, by "cool VM work" sure - if you mean unladen-swallows JIT. Anything else has a year+ lag time for inclusion to be seriously considered. Also, the funny thing with the GIL (even as the maintainer of multiprocessing) is that it's never bothered me. I've used hundreds of threads working with Queues/etc all the time. I actually don't use multiprocessing as much as I use plain old python threads.

by jnoller 16y ago

cdavid 16y ago

I think the problem is that python 3 is just different, without much improvements over 2 for many people. For example, the things which IMO were worth fixing at backward incompatibility price (like the import system, improved C API with ABI across minor versions, packaging) were not fixed. I have (in small parts) contributed to the python 3 conversion for numpy/scipy, and the only reason why I have done so is to be a good "python citizen", and because numpy is a major library in the python ecosystem. But I don't see any advantage in doing so. The cost is high, and the advantages near inexistent for me

jnoller 16y ago
You see - the reason your hit list of itches were not fixed were because no one stepped in to do them - this isn't anyones fault, but it doesn't mean important things were not fixed. Instead, the other itches (such as bytes vs. strings/unicode) were fixed. Function annotations, the standard library cleanup, and other things came along for the really big ride, which was the bytes/unicode/etc ride. So, there's lots of improvements that came with 3.0 - but the nice thing is is that it continues to evolve. We now have a New (more rational) GIL, we're probably going to have a futures package (http://www.python.org/dev/peps/pep-3148/ http://www.python.org/dev/peps/pep-3148/) and so on (heck, python3 is also getting a jit). And things will continue to be added. Everyone knows and admits that the transition will take years, but now with 2.x being "done" (meaning, no more releases past 2.7) and more great work being done in 3.x, hopefully people in general will start to see the benefits.

nailer 16y ago

Personally I don't know anyone who's running on 3.0 yet - so I think it will be a while before I get left behind.

jnoller 16y ago
And that was always the plan. 3.0 adoption was supposed to take several years. So it's all good - the big thing which needs to occur before most people will is some of the big libs need to port over.
- nailer 16y ago
  I also have the sneaking suspicion some of the cool VM work will end up being there around the same time (that said, I really like the Queue and Thread objects in 2.6 for most purposes, despite all the complaints people make about the GIL).
  - jnoller 16y ago
    Eh, by "cool VM work" sure - if you mean unladen-swallows JIT. Anything else has a year+ lag time for inclusion to be seriously considered. Also, the funny thing with the GIL (even as the maintainer of multiprocessing) is that it's never bothered me. I've used hundreds of threads working with Queues/etc all the time. I actually don't use multiprocessing as much as I use plain old python threads.