3 ms·

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

by 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.

by opencl 7y ago

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.