4 ms·

Wouldn't it be good to have Python 4.x next with all these workarounds cleaned up and with only one right pythonic way for parallel procesing? Surelly with a bi

Wouldn't it be good to have Python 4.x next with all these workarounds cleaned up and with only one right pythonic way for parallel procesing? Surelly with a bit of backward compatibility sacrificed like 2 vs 3.

anewhnaccount2 7y ago
Please no. There's a long tail of unmaintained but working libraries. Throwing away compatibility is not worth it.
- DonHopkins 7y ago
  Don't think of it as throwing away compatibility, it's just adding incompatibility. ;)
- azinman2 7y ago
  You could always have a compat API that’s different, or puts in “legacy” mode.
  - zbentley 7y ago
    In order for such an API to work, you'd have to bundle the vast majority of the existing Python runtime.
- stefano 7y ago
  You'd think people would learn from the 2to3 debacle.
_wmd 7y ago
Considering this will require basically a total rewrite of the C extension API, without having had a chance to look yet, the idea it could be done in a minor release seems shocking
stefano 7y ago
> Surelly with a bit of backward compatibility sacrificed like 2 vs 3. After 10 years, the 2to3 transition is still ongoing, and lots of companies will be dealing with python2 code for a long, long time. Breaking backward compatibility was a terrible decision. Breaking it again now that most libraries and open source projects have finally moved to python3 would be suicide. Programming languages should take backward compatibility as one of their most important features, because of the hundreds of millions of lines of code already written and that would need to be changed and validated. This is especially true in a dynamic language where you can't even rely on the compiler to point out the issues.
- gray_-_wolf 7y ago
  > dealing with python2 code for a long, long time. Won't python2 be EOLed sometime in 2020? Is someone expected to pick up security maintaince after that?
  - yjftsjthsd-h 7y ago
    Just because something is EOL/unmaintained doesn't mean that people stop using it.
FartyMcFarter 7y ago
Getting rid of the GIL would make the 2 to 3 transition look like kindergarten. There's lots and lots of Python code (and C extensions) that makes assumptions enabled by the GIL. For starters: If you get rid of CPython's atomic operations on lists and other simple objects, lots of Python code would need more locks than it needs now. If, on the other hand, you wish to keep those operations atomic, without the GIL that means introducing fine-grained locks on specific objects, which would worsen even single-threaded performance. Imagine taking a pthread mutex each time you append an item to every list or store a number in every variable.
upofadown 7y ago
It will probably come to something like that (for the Unicode issue alone) but it would be a disaster. Python has always had an issue with ongoing changes that break existing code. That was the idea behind Py3, that we would do all the breakage at once and be done with it forever. Ironically that made Py2 a much better target for a time as it was not changing very much.

anewhnaccount2 7y ago

Please no. There's a long tail of unmaintained but working libraries. Throwing away compatibility is not worth it.

DonHopkins 7y ago
Don't think of it as throwing away compatibility, it's just adding incompatibility. ;)
azinman2 7y ago
You could always have a compat API that’s different, or puts in “legacy” mode.
- zbentley 7y ago
  In order for such an API to work, you'd have to bundle the vast majority of the existing Python runtime.
stefano 7y ago
You'd think people would learn from the 2to3 debacle.

_wmd 7y ago

Considering this will require basically a total rewrite of the C extension API, without having had a chance to look yet, the idea it could be done in a minor release seems shocking

stefano 7y ago

> Surelly with a bit of backward compatibility sacrificed like 2 vs 3. After 10 years, the 2to3 transition is still ongoing, and lots of companies will be dealing with python2 code for a long, long time. Breaking backward compatibility was a terrible decision. Breaking it again now that most libraries and open source projects have finally moved to python3 would be suicide. Programming languages should take backward compatibility as one of their most important features, because of the hundreds of millions of lines of code already written and that would need to be changed and validated. This is especially true in a dynamic language where you can't even rely on the compiler to point out the issues.

gray_-_wolf 7y ago
> dealing with python2 code for a long, long time. Won't python2 be EOLed sometime in 2020? Is someone expected to pick up security maintaince after that?
- yjftsjthsd-h 7y ago
  Just because something is EOL/unmaintained doesn't mean that people stop using it.

FartyMcFarter 7y ago

Getting rid of the GIL would make the 2 to 3 transition look like kindergarten. There's lots and lots of Python code (and C extensions) that makes assumptions enabled by the GIL. For starters: If you get rid of CPython's atomic operations on lists and other simple objects, lots of Python code would need more locks than it needs now. If, on the other hand, you wish to keep those operations atomic, without the GIL that means introducing fine-grained locks on specific objects, which would worsen even single-threaded performance. Imagine taking a pthread mutex each time you append an item to every list or store a number in every variable.

upofadown 7y ago

It will probably come to something like that (for the Unicode issue alone) but it would be a disaster. Python has always had an issue with ongoing changes that break existing code. That was the idea behind Py3, that we would do all the breakage at once and be done with it forever. Ironically that made Py2 a much better target for a time as it was not changing very much.