3 ms·

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 ma

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
    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?
    - kevin_thibedeau 7y ago
      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.
      - sitkack 7y ago
        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.
- misnome 7y ago
  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).

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
  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?
  - kevin_thibedeau 7y ago
    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.
    - sitkack 7y ago
      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.
misnome 7y ago
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).