5 ms·

>Python3 does implicit float-to-int conversions differently I don't think so? Might be floating point division. > In Python 3.0, 5 / 2 will return 2.5 and 5 /

>Python3 does implicit float-to-int conversions differently I don't think so? Might be floating point division. > In Python 3.0, 5 / 2 will return 2.5 and 5 // 2 will return 2. The former is floating point division, and the latter is floor division, sometimes also called integer division. https://stackoverflow.com/questions/183853/what-is-the-difference-between-and-when-used-for-division https://stackoverflow.com/questions/183853/what-is-the-diffe... I think an automated tool like `2to3` is probably a better bet for doing that kind of conversion. It should be a mostly automatic process for most scripts.

opencl 7y ago
2to3 does NOT handle the change in division behavior. There is no automated way to do so because python2 only does floor division sometimes and it's decided at runtime based on the arguments being ints or not.
- fiddlerwoaroof 7y ago
  I believe you can get python3 behavior on a file by file basis with from __future__ import division But it’s been a while since I’ve written anything serious in python.
  - opencl 7y ago
    Yes you can, but this person needs the python2 behavior in python3 which pretty much requires selectively replacing / with //.
    - epylar 7y ago
      Yep, you can use // to get python2 behavior unless the object redefines __truediv__ but not __floordiv__
  - mumblemumble 7y ago
    That works for writing new code in Python 2.7. It would also have worked for going the recommended route of gradually migrating toward Python 3 compatibility while remaining on Python 2, _provided_ you're working with an organized project that's amenable to converting on a file-by-file basis. I can see where it falls flat on its face when you're trying to migrate a monolithic 6000-line script. But, IMO, that example falls flat on its face when used as a rhetorical device. If you've got a monolithic 6000-line script with (presumably) no test coverage, you've made your own bed, and I don't think that the inherent difficulties of maintaining something like that should be blamed exclusively on the 2->3 transition.
    - strenholme 7y ago
      In my experience in the business world, it is far too common to find a company’s critical infrastructure running on stuff more messy than this particular 6000-line monstrosity (which, for the record, I am not the original author of, and, yes, I have added a few test cases for code I have added to it like my own RNG). I once was getting paid double my previous salary to maintain Visual Basic code which makes this 6000-line script look like well structured fully tested object oriented code. When my boss came in to the room and said the project was cancelled, I let out a sigh of relief that I would never have to look at that code again. In terms of Python2, it will be maintained until at least 2024 because it’s part of CentOS/RHEL 7. I think it will be maintained until 2029 because I saw that package in CentOS 8, but I do not recall if it’s a core package with a guaranteed 2029 EOL.
      - jabl 7y ago
        Python 2 is not a core package in rhel8. You can get it via an extra collection that will be supported for the life of rhel7. So using rhel8 won't be a solution. Rhel developers are probably eager to drop Python 2 support as soon as possible. Which is when rhel7 goes EOL. Of course, it wouldn't particularly surprise me if customer pressure makes them support it for longer.
misnome 7y ago
I believe 2to3 hasn't been the entirely recommended way for a while - modernize (dual compatibility via the six module) and futurize (more magic to make as many python3 idioms work in 2 as possible) let you move towards python 3 without breaking compatibility from python 2, and give you ways of working in both versions at once - 2to3 isn't even mentioned on https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html. That said, syntax conversion is usually only a small part of the problem - unicode handling can be more problematic, especially if you've never spent much time thinking about or working with encoding/decoding. It's definitely _much_ easier if you have a good grasp of both versions of the language and the changes that were made, and it isn't helped by the pervasive myth that "It's just brackets on print statements". We recently converted a ~900kloc open source codebase to dual python 2/3 with many scattered interested parties and approached it in roughly a phased way - Using CI to prevent backsliding of syntax converted portions of the codebase and getting the tests running (and failing) in python3 early were crucial. (To add to this - a very _early_ step was getting the future imports in place - every file had future absolute_import, division imported at a very early stage. For division, you can also start python2 with -Qnew and it'll force all division to "modern" style).
- kevin_thibedeau 7y ago
  Six is just trading dependency on py2 for dependency on a library that wouldn't otherwise be needed if you just made a code base forward compatible. It is more sensible to gradually work on getting 2to3 to do a clean conversion and then doing a final conversion when the py2 code is ready to be EOLed.
  - sitkack 7y ago
    You are arguing for a hard cutover, which is how we got into this mess in the first place. By using a forward or backward shim, one can run on both. 2to3 is a CASE tool, it requires manual fixup, so it cannot be used to maintain a dual version codebase.
    - misnome 7y ago

opencl 7y ago

2to3 does NOT handle the change in division behavior. There is no automated way to do so because python2 only does floor division sometimes and it's decided at runtime based on the arguments being ints or not.

fiddlerwoaroof 7y ago
I believe you can get python3 behavior on a file by file basis with from __future__ import division But it’s been a while since I’ve written anything serious in python.
- opencl 7y ago
  Yes you can, but this person needs the python2 behavior in python3 which pretty much requires selectively replacing / with //.
  - epylar 7y ago
    Yep, you can use // to get python2 behavior unless the object redefines __truediv__ but not __floordiv__
- mumblemumble 7y ago
  That works for writing new code in Python 2.7. It would also have worked for going the recommended route of gradually migrating toward Python 3 compatibility while remaining on Python 2, _provided_ you're working with an organized project that's amenable to converting on a file-by-file basis. I can see where it falls flat on its face when you're trying to migrate a monolithic 6000-line script. But, IMO, that example falls flat on its face when used as a rhetorical device. If you've got a monolithic 6000-line script with (presumably) no test coverage, you've made your own bed, and I don't think that the inherent difficulties of maintaining something like that should be blamed exclusively on the 2->3 transition.
  - strenholme 7y ago
    In my experience in the business world, it is far too common to find a company’s critical infrastructure running on stuff more messy than this particular 6000-line monstrosity (which, for the record, I am not the original author of, and, yes, I have added a few test cases for code I have added to it like my own RNG). I once was getting paid double my previous salary to maintain Visual Basic code which makes this 6000-line script look like well structured fully tested object oriented code. When my boss came in to the room and said the project was cancelled, I let out a sigh of relief that I would never have to look at that code again. In terms of Python2, it will be maintained until at least 2024 because it’s part of CentOS/RHEL 7. I think it will be maintained until 2029 because I saw that package in CentOS 8, but I do not recall if it’s a core package with a guaranteed 2029 EOL.
    - jabl 7y ago
      Python 2 is not a core package in rhel8. You can get it via an extra collection that will be supported for the life of rhel7. So using rhel8 won't be a solution. Rhel developers are probably eager to drop Python 2 support as soon as possible. Which is when rhel7 goes EOL. Of course, it wouldn't particularly surprise me if customer pressure makes them support it for longer.

misnome 7y ago

I believe 2to3 hasn't been the entirely recommended way for a while - modernize (dual compatibility via the six module) and futurize (more magic to make as many python3 idioms work in 2 as possible) let you move towards python 3 without breaking compatibility from python 2, and give you ways of working in both versions at once - 2to3 isn't even mentioned on https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html. That said, syntax conversion is usually only a small part of the problem - unicode handling can be more problematic, especially if you've never spent much time thinking about or working with encoding/decoding. It's definitely _much_ easier if you have a good grasp of both versions of the language and the changes that were made, and it isn't helped by the pervasive myth that "It's just brackets on print statements". We recently converted a ~900kloc open source codebase to dual python 2/3 with many scattered interested parties and approached it in roughly a phased way - Using CI to prevent backsliding of syntax converted portions of the codebase and getting the tests running (and failing) in python3 early were crucial. (To add to this - a very _early_ step was getting the future imports in place - every file had future absolute_import, division imported at a very early stage. For division, you can also start python2 with -Qnew and it'll force all division to "modern" style).

kevin_thibedeau 7y ago
Six is just trading dependency on py2 for dependency on a library that wouldn't otherwise be needed if you just made a code base forward compatible. It is more sensible to gradually work on getting 2to3 to do a clean conversion and then doing a final conversion when the py2 code is ready to be EOLed.
- sitkack 7y ago
  You are arguing for a hard cutover, which is how we got into this mess in the first place. By using a forward or backward shim, one can run on both. 2to3 is a CASE tool, it requires manual fixup, so it cannot be used to maintain a dual version codebase.
  - misnome 7y ago