Hacker News Reader

Comment by traverseda | Hacker News Reader

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

View on HN

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.

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

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.

I'm reading "getting 2to3 to do a clean conversion" as having a python2 codebase but then running 2to3 to build a "python3" version before deployment. If I recall, that was touted as the approach in the early days of python3 and conversions. I haven't seen it used or talked about much, recently, although I'm aware that later tools like pasteurize attempt to do the reverse (but haven't tried them).

I worry that doing this would basically cause much of the pain of maintaining separate codebases - inevitable bugs that affect one or the other, with the problem of not being able to directly write in one of them, and getting to where you have to check both for new code. Plus, it doesn't cover everything (or can't - e.g. ambiguous cases were removed), and has a few places where it makes mistakes (have seen but cannot recall) - so you end up having to write cross-compatible code for some things yourself anyway.

I feel that extra dependencies, especially commonly known, understood and reasonably well documented ones, is an extremely small price to pay.

We decided early on for our large project that developing separately and having a version shear where we "switched" to python3 would probably be chaos. The slow and gentle way, you can make changes and adjust the other developers at a more reasonable pace, the point at which you drop python2 is merely a decision with an empty changelog (at which point you can start stripping stuff out).

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.

I read their argument as, getting the codebase to the point at which running 2to3 completes the transformation. I personally remain unconvinced that that code wouldn't require the equivalent of a compatibility library anyway.

And, do hard cutovers ever work well?

It's the same work as porting to a compatibility library but you don't have to carry any legacy long into the future once the port is finished.

This is a hard cut over from Python2 to 3. This presupposes that both upstream and downstream deps are on Python3. On which magical day does everyone decide "to have their port finished" ?

If it is the same work to to support both 2 and 3 as jettison support for 2 in favor of three. Then supporting both so the system can actually upgrade is far preferable. Applications and libraries not used in isolation. To jettison support while the rest of the dependency graph is flux is analogous to gimbal lock, you can't just get here from there. Without `six` the whole Python ecosystem would have bifurcated and Python2 would still be the dominant Python.

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.

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.

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.

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.

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.

Yes you can, but this person needs the python2 behavior in python3 which pretty much requires selectively replacing / with //.

Yep, you can use // to get python2 behavior unless the object redefines __truediv__ but not __floordiv__

Reply on news.ycombinator.com