5 ms·

I still don't think that any of those new functions justifies the need of a total compatibility breakdown, like the one that was artificially induced from pytho

I still don't think that any of those new functions justifies the need of a total compatibility breakdown, like the one that was artificially induced from python2.7 to python3. Python3 is good, but should have happened as a smooth transition from python2.7. The way it was handled was just a mess, and still keeps polluting the Python world. Next time somebody asks what Java has over Python... here it is: nothing like the python 2 vs 3 mess.

phire 9y ago
Honestly, if they had just keep the print statement, the push back would have been almost non-existent. It was that one change that pushed python 3 from "some programs and libraries will need to be written" to "almost every single program and intro to python tutorial needs to change".
- seanwilson 9y ago
  How hard would it have been to allow Python 2 and 3 code files to be mixed?
  - minitech 9y ago
    That’s a giant can of worms. One example problem: Python 2 has a type of class (old-style) that doesn’t exist in Python 3. What happens when you try to pass this type of class or one of its instances between the languages? There’s a bunch of stuff like that. You’d end up with a very weighed-down interpreter with a bunch of caveats if you ended up with one at all.
    - seanwilson 9y ago
      Would doing that then deprecating those features after 5 years or so not be better than what's happened with the Python 3 transition? I'm curious what options there are for how to make such a transition smoother.
      - minitech 9y ago
        The important part of Python 3 is the bytes/str/unicode rework, and there’s no way to make that not a breaking change. Everything else is minor stuff that’s allowed to be breaking because the str change already broke backwards compatibility. (And yes, making strings text rather than bytes was really that important. Python 3 would be a huge improvement even if it were only that and some other safety things like removing the default ordering of incompatible types.)
    - tripzilch 9y ago
      Oh man, I almost forgot about the old-style classes thing, haha :) That seems like ages ago (and it is ..)
- jxramos 9y ago
  2to3 should manage all that sort of low hanging fruit automatically. The real meat comes in the byte array string logic preservation or breakage.
shezi 9y ago
I'd like to respectfully disagree. I don't believe that there is a way to change how one of the fundamental types of a language works (string/unicode vs bytes/string) and make that a "smooth" transition. I know that is causes a lot of strain in the python community, but I applaud the core developers for doing that change, instead of getting stuck in the well-known "we have to support all legacy versions" hell.

phire 9y ago

Honestly, if they had just keep the print statement, the push back would have been almost non-existent. It was that one change that pushed python 3 from "some programs and libraries will need to be written" to "almost every single program and intro to python tutorial needs to change".

seanwilson 9y ago
How hard would it have been to allow Python 2 and 3 code files to be mixed?
- minitech 9y ago
  That’s a giant can of worms. One example problem: Python 2 has a type of class (old-style) that doesn’t exist in Python 3. What happens when you try to pass this type of class or one of its instances between the languages? There’s a bunch of stuff like that. You’d end up with a very weighed-down interpreter with a bunch of caveats if you ended up with one at all.
  - seanwilson 9y ago
    Would doing that then deprecating those features after 5 years or so not be better than what's happened with the Python 3 transition? I'm curious what options there are for how to make such a transition smoother.
    - minitech 9y ago
      The important part of Python 3 is the bytes/str/unicode rework, and there’s no way to make that not a breaking change. Everything else is minor stuff that’s allowed to be breaking because the str change already broke backwards compatibility. (And yes, making strings text rather than bytes was really that important. Python 3 would be a huge improvement even if it were only that and some other safety things like removing the default ordering of incompatible types.)
  - tripzilch 9y ago
    Oh man, I almost forgot about the old-style classes thing, haha :) That seems like ages ago (and it is ..)
jxramos 9y ago
2to3 should manage all that sort of low hanging fruit automatically. The real meat comes in the byte array string logic preservation or breakage.

shezi 9y ago

I'd like to respectfully disagree. I don't believe that there is a way to change how one of the fundamental types of a language works (string/unicode vs bytes/string) and make that a "smooth" transition. I know that is causes a lot of strain in the python community, but I applaud the core developers for doing that change, instead of getting stuck in the well-known "we have to support all legacy versions" hell.