>>> >>> Regarding Python 3: >>> Would you drop Python 2 support or do you want to support Python 2/3 in parallel? I would prefer the former… >> >> For quite some time we would need to support both; we can't just have >> a release of git that one day breaks git-p4 for people stuck on Python >> 2. But it might not be that hard to support both (though converting >> all those print statements could be quite tiresome). > Agreed. However supporting both versions increases code complexity as well as testing effort. Would a compromise like the following work? We fork “git-p4.py” to “git-p4-python2.py” and just apply important bug fixes to that file. All new development happens on a Python 3 only git-p4.py. I'm not a python expert, but I think we're quite a way from that point anyway. I think we'd want to run 2to3 on it and make it work - at that point it should work on both python 2.7 (and earlier? I don't know) and python 3.x. By the time that's done, we may well find that we _can_ just drop python2 support, or fork, as you suggest. Running 2to3 also includes adding test cases for all the code that is in there that's not currently covered so that end-users don't find out the hard way that we've missed bits. That's why I think it's a fairly long-term goal. Regardless, I think we'd want to have a wider discussion about the best way forward, and there doesn't seem much point having that discussion now when there's no actual code! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html