5 ms·

There will be many Python 2 production codebases that will forever remain at Python 2. Whether Python 3 is a new language or not will not make a difference.

cookiecaper 10y ago
I really don't understand why. Python 3 is not a radical departure and the usual complaint is the dependency graph. Over the last 18 months that has really healed up, to the point where the Wall of Superpowers is almost 100% green. I understand that some people want to keep old code running as long as humanly possible, which is their prerogative. But there's no reason to imply that conversion to Py3 is unduly difficult or something that shouldn't be undertaken, even for large/complex codebases. If Google can write grumpy to transpile Python code to Go, there's no reason it can't improve 2to3 to handle their incompatibilities.
- scrollaway 10y ago
  I think the main issue is library compatibility, which gives people the impression that compatibility is an unreachable target. The truth is, once most libraries are 3.x compatible, porting is very easy (as easy as a 2.x -> 2.y transition). And now, we've reached that point. People are starting to catch up. There are some exceptions of course, those who heavily rely on 2.x unicode behaviour and such, but all in all they are rare. So now, it's much easier than it used to be.
  - eikenberry 10y ago
    > as easy as a 2.x -> 2.y transition You mean I can just run all my python2 programs with python3 runtime with no changes at all. Because that was how every upgrade before python3 went.
    - scrollaway 10y ago
      Nearly all my code co-runs on 2.7 / 3.6 with almost no hacks. So, yes.
      - Chris2048 10y ago
        And your code is all code?
        scrollaway 10y ago
        https://github.com/jleclanche https://github.com/jleclanche The code that doesn't run on Python 2+3 only runs on Python 3. Have at it.
        Chris2048 10y ago
        What is your point here?
        scrollaway 10y ago
        What is yours? You're the one asking.
        Chris2048 10y ago
        Asking what? eikenberry asked: "can just run all my python2 programs with python3 runtime with no changes at all" You replied: "Nearly all my code co-runs on 2.7 / 3.6 with almost no hacks. So, yes.", implying that, yes, you can run py2 programs without change, because this is true of your code To which I replied "And your code is all code?"; Meaning, just because this is true of your code, doesn't mean it is true of eikenberry's code, or any/all code. You then responded with a project that apparently runs fully on py3, but only partially on py2 - what is the point you are making by posting that project?
    - pekk 10y ago
      This is simply not true. For example, Python 2.6 deprecated string exceptions. If you expect in any language to write code and have it run forever, you expect that language never to change.
      - cookiecaper 10y ago
        Yep. It's not Python-exclusive either. I can't upgrade to Ruby 2.4 yet because one of my dependencies hasn't been updated. Breaking changes are a routine thing in any maintained language; heck, even a conservative project like GCC breaks code between major releases.
      - Chris2048 10y ago
        Were string exceptions deprecated in 2.6 because they don't exist in py3?
        scrollaway 10y ago
        String exceptions don't exist in py3 because they were deprecated in 2.6.
- sigjuice 10y ago
  What is the largest Python 2 codebase you can point at which has gone Python 3?
  - carreau 10y ago
    Django.
  - collinmanderson 10y ago
    OpenStack is quite large, and it's almost done. https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_O... http://fedora.portingdb.xyz/grp/openstack/ http://fedora.portingdb.xyz/grp/openstack/
- jedberg 10y ago
  I was going to say "because hosted solutions don't support Python 3" but I see that two days ago Amazon announced Lambda support for Python 3, which was my big holdup. So I guess it's time for me to get on board with Python3!
- rsj_hn 10y ago
  "I really don't understand why." Because you are suffering from the exponential growth mindset, in which the next new thing is as important as the sum total of all things that came before it. In that mindset, the future is emphasized and the past is heavily discounted. http://idlewords.com/talks/web_design_first_100_years.htm http://idlewords.com/talks/web_design_first_100_years.htm But that mindset is not shared by most firms in most industries, it's a unique pathology to the web. Businesses don't re-write working code just because a newer language version is available. Landlords don't tear down old apartment buildings just because more efficient building technologies are available. We live in a world in which COBOL runs a lot of mission critical code. Anything that touches important code that is now working is a risk and an expense, and what is the tangible gain for undertaking this expense? What new features will be added? How much more revenue will you get? What is the opportunity cost of having your engineers do that than something else, like adding a feature or improving test coverage? Before you say that it's simple, be aware that you are talking about messing with libraries that may not be maintained anymore. You are going to spend a lot of time debugging those old libraries as well as writing unit tests for them. Nothing in the world of software engineering is simple, especially when it comes to maintaining a large body of scripts. Imagine if in the Java world, it was announced that the Java 8 runtime would not support running Java 6 or older jars. How many jars are businesses running that were written in 2005? No one even know who wrote those libraries. Suppose in the C world, it was announced that code written in C'99 and before would no longer compile. The Linux kernel has code written in the 90s, and GCC has code written in the 70s and it's still supposed to compile under the most modern compiler. Moreover automated code re-writing tools don't come with guarantees of soundness or accuracy. There will be breakage, it will occur in random places, and there is zero upside to spending a lot of money to get an existing project to the same level of functionality as it had before you started messing with it. People who work in other languages get this. It's really not a difficult concept. Everyone other than the Python community agrees that Python did a massive screw up with python 3, just as the Perl community committed suicide by making Perl 6 not be compatible with Perl 5. I don't pretend to know what will be the future of Python -- maybe there isn't enough enterprise users out there to make a difference for the direction of the language -- but you do need to understand why breaking existing code is a deal breaker for the majority of business customers. You may disagree, but at least don't pretend that there is some irrational mysterious resistance to converting python2 code to python3.

cookiecaper 10y ago

I really don't understand why. Python 3 is not a radical departure and the usual complaint is the dependency graph. Over the last 18 months that has really healed up, to the point where the Wall of Superpowers is almost 100% green. I understand that some people want to keep old code running as long as humanly possible, which is their prerogative. But there's no reason to imply that conversion to Py3 is unduly difficult or something that shouldn't be undertaken, even for large/complex codebases. If Google can write grumpy to transpile Python code to Go, there's no reason it can't improve 2to3 to handle their incompatibilities.

scrollaway 10y ago
I think the main issue is library compatibility, which gives people the impression that compatibility is an unreachable target. The truth is, once most libraries are 3.x compatible, porting is very easy (as easy as a 2.x -> 2.y transition). And now, we've reached that point. People are starting to catch up. There are some exceptions of course, those who heavily rely on 2.x unicode behaviour and such, but all in all they are rare. So now, it's much easier than it used to be.
- eikenberry 10y ago
  > as easy as a 2.x -> 2.y transition You mean I can just run all my python2 programs with python3 runtime with no changes at all. Because that was how every upgrade before python3 went.
  - scrollaway 10y ago
    Nearly all my code co-runs on 2.7 / 3.6 with almost no hacks. So, yes.
    - Chris2048 10y ago
      And your code is all code?
      - scrollaway 10y ago
        https://github.com/jleclanche https://github.com/jleclanche The code that doesn't run on Python 2+3 only runs on Python 3. Have at it.
        Chris2048 10y ago
        What is your point here?
        scrollaway 10y ago
        What is yours? You're the one asking.
        Chris2048 10y ago
        Asking what? eikenberry asked: "can just run all my python2 programs with python3 runtime with no changes at all" You replied: "Nearly all my code co-runs on 2.7 / 3.6 with almost no hacks. So, yes.", implying that, yes, you can run py2 programs without change, because this is true of your code To which I replied "And your code is all code?"; Meaning, just because this is true of your code, doesn't mean it is true of eikenberry's code, or any/all code. You then responded with a project that apparently runs fully on py3, but only partially on py2 - what is the point you are making by posting that project?
  - pekk 10y ago
    This is simply not true. For example, Python 2.6 deprecated string exceptions. If you expect in any language to write code and have it run forever, you expect that language never to change.
    - cookiecaper 10y ago
      Yep. It's not Python-exclusive either. I can't upgrade to Ruby 2.4 yet because one of my dependencies hasn't been updated. Breaking changes are a routine thing in any maintained language; heck, even a conservative project like GCC breaks code between major releases.
    - Chris2048 10y ago
      Were string exceptions deprecated in 2.6 because they don't exist in py3?
      - scrollaway 10y ago
        String exceptions don't exist in py3 because they were deprecated in 2.6.
sigjuice 10y ago
What is the largest Python 2 codebase you can point at which has gone Python 3?
- carreau 10y ago
  Django.
- collinmanderson 10y ago
  OpenStack is quite large, and it's almost done. https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_O... http://fedora.portingdb.xyz/grp/openstack/ http://fedora.portingdb.xyz/grp/openstack/
jedberg 10y ago
I was going to say "because hosted solutions don't support Python 3" but I see that two days ago Amazon announced Lambda support for Python 3, which was my big holdup. So I guess it's time for me to get on board with Python3!
rsj_hn 10y ago
"I really don't understand why." Because you are suffering from the exponential growth mindset, in which the next new thing is as important as the sum total of all things that came before it. In that mindset, the future is emphasized and the past is heavily discounted. http://idlewords.com/talks/web_design_first_100_years.htm http://idlewords.com/talks/web_design_first_100_years.htm But that mindset is not shared by most firms in most industries, it's a unique pathology to the web. Businesses don't re-write working code just because a newer language version is available. Landlords don't tear down old apartment buildings just because more efficient building technologies are available. We live in a world in which COBOL runs a lot of mission critical code. Anything that touches important code that is now working is a risk and an expense, and what is the tangible gain for undertaking this expense? What new features will be added? How much more revenue will you get? What is the opportunity cost of having your engineers do that than something else, like adding a feature or improving test coverage? Before you say that it's simple, be aware that you are talking about messing with libraries that may not be maintained anymore. You are going to spend a lot of time debugging those old libraries as well as writing unit tests for them. Nothing in the world of software engineering is simple, especially when it comes to maintaining a large body of scripts. Imagine if in the Java world, it was announced that the Java 8 runtime would not support running Java 6 or older jars. How many jars are businesses running that were written in 2005? No one even know who wrote those libraries. Suppose in the C world, it was announced that code written in C'99 and before would no longer compile. The Linux kernel has code written in the 90s, and GCC has code written in the 70s and it's still supposed to compile under the most modern compiler. Moreover automated code re-writing tools don't come with guarantees of soundness or accuracy. There will be breakage, it will occur in random places, and there is zero upside to spending a lot of money to get an existing project to the same level of functionality as it had before you started messing with it. People who work in other languages get this. It's really not a difficult concept. Everyone other than the Python community agrees that Python did a massive screw up with python 3, just as the Perl community committed suicide by making Perl 6 not be compatible with Perl 5. I don't pretend to know what will be the future of Python -- maybe there isn't enough enterprise users out there to make a difference for the direction of the language -- but you do need to understand why breaking existing code is a deal breaker for the majority of business customers. You may disagree, but at least don't pretend that there is some irrational mysterious resistance to converting python2 code to python3.