python2 isn't available on OS X

[jdelStrother]

Don't know if you were aware of this, but python2 isn't available on OS X, so I had to create a symlink before I could run imerge. On 10.8, the python binary is 2.7.2.

I've not got much experience with python... I assume python2 is there for a good reason?

[mhagger]

python2 is there because git-imerge requires Python version 2.x as opposed to Python 3.x (or, God forbid, Python 1.x). According to PEP 394, it is recommended that some Python 2.x interpreter be installed in PATH under the name "python2". I understand that this is not yet universal practice, but on the other hand there are already systems where "python" is a Python version 3.x interpreter, so that option is also not universally portable.

By the way, I think that any Python interpreter version 2.5 <= version < 3.0 should be fine for git-imerge.

[myint]

I resolved this by supporting both Python 2 and 3. @mhagger, if you are interested, I can either send a pull requests or you can just merge my fork. The continuous integration server shows the test results.

[mhagger]

@myint, that's really cool! I hadn't yet had the energy to get any of my projects running under Python3. It's a lot less nasty than I would have feared.

I just pushed some commits to master that incorporate some of the changes from your first commit. The remainder of your changes (i.e., after the already-merged changes have been removed) are in my repo under branch myint/python3. But before I merge the rest, I would like to understand the ramifications a little bit better.

What is the situation on the Mac OSX? (Is that is what you are using?) Is Python 2.x unavailable, or is it available, but just not under the name python2? In other words, are these changes needed to make the script usable under Mac OSX at all, or just to avoid having to edit the shebang line?

(If the latter, then there are other ways to make sure that a Python 2.x interpreter is used to run the script. Either the script can be given a Shell preamble that chooses the correct Python interpreter, or we could add an install script that overwrites the shebang line with the one correct for the system that it is running on. Not that python3 compatibility is something bad, but reducing the python2 compatibility might still be inconvenient for some users.)

Before these changes, I think that git-imerge would have worked under Python versions 2.5 <= version < 3.0 (though I haven't actually tested it against the older versions). The changes I just pushed now prevent it from running under 2.5 (because it doesn't have the next() built-in function). With the rest of your changes, what versions of Python should it run under? Only 2.7 and 3.3? Assuming that is the case, we should probably verify that the important recent OSs make one of these Python versions available.

Thanks again for your contribution!

[jdelStrother]

Python 2.x comes installed on OS X, as python. OS X 10.9 comes with python 2.7.5. There's no python2 by default

[myint]

Like @jdelStrother mentioned, python2 doesn't exist on OS X. An OS X user could just create a symlink called python2 and point it to /usr/bin/python. I happen to use Python 3 by default so my use case only tangentially relates to this issue (#18).

I've enabled the Python 2.6 test on Travis CI (450e728). It works. See test results here.

I could enable Python 2.5 support, but the code will get a bit uglier. (The as exception syntax, which Python 3 requires, isn't supported in Python 2.5 and there are a few other things like what you mentioned.) And I think the trend in Python now is to support Python 2.6, 2.7, and 3.3.

[mhagger]

@myint: Thanks for the additional info. I was confused; I thought that "except E as T" syntax wasn't added until Python 2.7. Now I see that it was backported to Python 2.6.1.

So if we merge your changes, I think our Python version requirement would become

(2.6.1 <= version < 3.0) or (3.3 <= version)

(that is, unless something else that you are using was introduced even later than 2.6.1). I think we can live with that. I just merged your change (though the commit identities have changed, so you might want to pull from me again).

Thanks!

[myint]

Great! By the way, as far as I know the as exception syntax was introduced in Python 2.6 proper. The 2.6.1 change log mentions it too, but only because the change log is cumulative. (I don't think Python developers introduce syntax changes in patch releases.)

[mhagger]

@myint: I was going by the language reference for 2.6 vs 2.6.1. The as syntax wasn't mentioned until 2.6.1. But given that it is mentioned in the changelog for 2.6, I assume that it was implemented then and they just didn't get around to updating the language reference in time for the release.

I'll fix the README.