3 ms·

All you need to do to make this work with Python 3 is change your print statements (add parentheses) and change raw_input to input, as far as I can tell running

All you need to do to make this work with Python 3 is change your print statements (add parentheses) and change raw_input to input, as far as I can tell running it in python 3 locally. It seems to work perfectly with these ~20 seconds of changes.

e12e 7y ago
Sounds like 2to3 should be able to magically fix it? I suppose adding "from future import print" and similar for input would keep it working for python2 too? Ed: i think that should be: from builtins import input from __future__ import print_function
- fredley 7y ago
  Don't bother with python 2 compatibility, it's EOL in a few months. And 2to3 will probably work but even that is more effort than it needs to be.
  - vorg 7y ago
    An official "EOL" from the Python Benevolency doesn't mean Python 2 has reached the end of its life. There's too many projects out there using it for the same reasons this one is, i.e. "Because I started this project in 2011, though, with Python 2, you will need Python 2". Both Python 2 and Python 3 will continue to exist for active projects for a long time yet. All programming languages have this issue, though many try to hide it, such as Apache Groovy. In 2012, Groovy 2 shipped as two separate compilers bundled together, one was a continuation of Groovy 1 and the other was the new edition with the invoke-dynamic capabilities. A few weeks ago, the Groovy Committee decided to keep these separate in the bundle for the upcoming Groovy 3 release, add the new features such as the parser upgrade from Antlr 2 to Antlr 4 to the invoke-dynamic compiler only, and keep the other compiler (the one actually used by Gradle and Jenkins and everyone else) at the Groovy 1 capabilities. So virtually everyone will be using the old antlr2 parser and slower dynamic function dispatches in Apache Groovy for a long time yet, something which the Groovy project managers are deliberately doing to cater for all the legacy Groovy code out there.

e12e 7y ago

Sounds like 2to3 should be able to magically fix it? I suppose adding "from future import print" and similar for input would keep it working for python2 too? Ed: i think that should be: from builtins import input from __future__ import print_function

fredley 7y ago
Don't bother with python 2 compatibility, it's EOL in a few months. And 2to3 will probably work but even that is more effort than it needs to be.
- vorg 7y ago
  An official "EOL" from the Python Benevolency doesn't mean Python 2 has reached the end of its life. There's too many projects out there using it for the same reasons this one is, i.e. "Because I started this project in 2011, though, with Python 2, you will need Python 2". Both Python 2 and Python 3 will continue to exist for active projects for a long time yet. All programming languages have this issue, though many try to hide it, such as Apache Groovy. In 2012, Groovy 2 shipped as two separate compilers bundled together, one was a continuation of Groovy 1 and the other was the new edition with the invoke-dynamic capabilities. A few weeks ago, the Groovy Committee decided to keep these separate in the bundle for the upcoming Groovy 3 release, add the new features such as the parser upgrade from Antlr 2 to Antlr 4 to the invoke-dynamic compiler only, and keep the other compiler (the one actually used by Gradle and Jenkins and everyone else) at the Groovy 1 capabilities. So virtually everyone will be using the old antlr2 parser and slower dynamic function dispatches in Apache Groovy for a long time yet, something which the Groovy project managers are deliberately doing to cater for all the legacy Groovy code out there.