3 ms·

>Categorically demanding complete backward compatibility puts huge limitations on the development of the language Not really. Just introduce an optional versio

by dTal 6y ago

>Categorically demanding complete backward compatibility puts huge limitations on the development of the language Not really. Just introduce an optional version declaration at the top of the file, which guarantees the old behavior. Then feel free to tinker with the design as much as you want. It's a solved problem and it works well. Sure, you still break people's code if they don't put a version declaration in - but now the fix is a single line. The fatal flaw in Python's approach was cleaving apart the Python2 and Python3 worlds, making it impossible to mutually import modules. Python2 and Python3 are practically speaking different languages - different syntax, different semantics, different libraries, and a different userbase. As far as the computer is concerned, they are separate entities, with the feeble "2to3" program being the only thing linking them.

takeda 6y ago
Actually I did some small tests, and you could mix python2 and python3 code together through use of Cython. You can use Cython to compile your python 2 code into .so objects and then include them in Python 3. Then you can progressively migrate code file by file to Python 3. I didn't do it on a larger project, so maybe there are some gotchas, but it seems to work as far as I could test it. Regarding the differences in languages Python 2.7 was actually a bridge to migrate to Python 3. That's why all features of 2.7 were backported from 3 (this was also the reason people saying: "why should I migrate to 3, it doesn't offere anything new". It didn't because everything new was backported. Anyway thanks to this it was actually possible to write code that worked on both Python version. I did it several times. It was actually the easiest when you wrote the code for Python 3 and only used features that 2 had. Add all the `__future__` imports and remaining parts filled with the `six` module.
- xapata 6y ago
  The Cython translation is really clever.
GeorgeTirebiter 6y ago
Yes. "from __future__ import ..." could have had "from __past__ import ..." or some other such 1-line mechanism to maintain compatibility. Before the switch to P3, I argued vehemently with (some of) The Powers that Be that doing this was unnecessary and would break the community. The argument was, "Don't worry, P3 is so much better, people will want to change over." Well, yeah, maybe. Personally, I ignored P3 until 3.6 arrived. THAT was enough of a jump to abandon P2.
- donor20 6y ago
  Similar story here, 3.5 was first version that was even practical to really consider (they kept on making the compat story a bit better because they FINALLY listened to folks). I really wish you and others had more luck earlier, the transition did not need to be nearly as painful.
jnxx 6y ago
> Python2 and Python3 are practically speaking different languages - different syntax, different semantics, different libraries, and a different userbase. Yes, and tools and infractstructure should account for that: Python 2 and Python 3 should use different file extensions, and libraries written for python 2 should not just adapt to Python 3 and break backward compatibility, but come _at least_ as a new major version - better with a different library name, as Go lang requires. And still it would have been possible to support Unicode in python 3 without breaking backwards compatibility. It was possible to support in Common Lisp which was defined as a ANSI standard in 1994, and Common Lisp implementations like SBCL or Schemes compile to far faster code than C Python (while providing many of its flow control affordances, like list comprehensions, or a numeric tower). Why should it not be possible for Python? Apart from the developers not wanting to do it?

by dTal 6y ago

takeda 6y ago

Actually I did some small tests, and you could mix python2 and python3 code together through use of Cython. You can use Cython to compile your python 2 code into .so objects and then include them in Python 3. Then you can progressively migrate code file by file to Python 3. I didn't do it on a larger project, so maybe there are some gotchas, but it seems to work as far as I could test it. Regarding the differences in languages Python 2.7 was actually a bridge to migrate to Python 3. That's why all features of 2.7 were backported from 3 (this was also the reason people saying: "why should I migrate to 3, it doesn't offere anything new". It didn't because everything new was backported. Anyway thanks to this it was actually possible to write code that worked on both Python version. I did it several times. It was actually the easiest when you wrote the code for Python 3 and only used features that 2 had. Add all the `__future__` imports and remaining parts filled with the `six` module.

xapata 6y ago
The Cython translation is really clever.

GeorgeTirebiter 6y ago

Yes. "from __future__ import ..." could have had "from __past__ import ..." or some other such 1-line mechanism to maintain compatibility. Before the switch to P3, I argued vehemently with (some of) The Powers that Be that doing this was unnecessary and would break the community. The argument was, "Don't worry, P3 is so much better, people will want to change over." Well, yeah, maybe. Personally, I ignored P3 until 3.6 arrived. THAT was enough of a jump to abandon P2.

donor20 6y ago
Similar story here, 3.5 was first version that was even practical to really consider (they kept on making the compat story a bit better because they FINALLY listened to folks). I really wish you and others had more luck earlier, the transition did not need to be nearly as painful.

jnxx 6y ago

> Python2 and Python3 are practically speaking different languages - different syntax, different semantics, different libraries, and a different userbase. Yes, and tools and infractstructure should account for that: Python 2 and Python 3 should use different file extensions, and libraries written for python 2 should not just adapt to Python 3 and break backward compatibility, but come _at least_ as a new major version - better with a different library name, as Go lang requires. And still it would have been possible to support Unicode in python 3 without breaking backwards compatibility. It was possible to support in Common Lisp which was defined as a ANSI standard in 1994, and Common Lisp implementations like SBCL or Schemes compile to far faster code than C Python (while providing many of its flow control affordances, like list comprehensions, or a numeric tower). Why should it not be possible for Python? Apart from the developers not wanting to do it?