Pete Wyckoff <p...@padd.com>: > e...@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500: > > diff --git a/git-p4.py b/git-p4.py > > index 551aec9..ec060b4 100755 > > --- a/git-p4.py > > +++ b/git-p4.py > > @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve > > import tempfile, getopt, os.path, time, platform > > import re, shutil > > > > +if sys.hexversion < 0x02040000: > > + # The limiter is the subprocess module > > + sys.stderr.write("git-p4.py: requires Python 2.4 or later.") > > + sys.exit(1) > > + > > verbose = False > > If 2.3 does not have the subprocess module, this script will fail > at the import, and not run your version test.
Yes, the import of subprocess should move to after the check. > All the uses of sys.stderr.write() should probably include a > newline. Presumably you used write instead of print to avoid > 2to3 differences. That is correct. > The name of this particular script, as users would type it, is > "git p4"; no dash and no ".py". > > Many of your changes have these three problems; I just picked on > my favorite one. Should I resubmit, or do you intend to fix these while merging? > > diff --git a/git-remote-testgit.py b/git-remote-testgit.py > > index 5f3ebd2..22d2eb6 100644 > > --- a/git-remote-testgit.py > > +++ b/git-remote-testgit.py > > @@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter > > from git_remote_helpers.git.importer import GitImporter > > from git_remote_helpers.git.non_local import NonLocalGit > > > > +if sys.hexversion < 0x01050200: > > + # os.makedirs() is the limiter > > + sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or > > later.") > > + sys.exit(1) > > + > > This one, though, is a bit of a lie because git_remote_helpers > needs 2.4, and you add that version enforcement in the library. Agreed. The goal here was simply to have the depedencies of the individual scripts be clearly documented, and establish a practice for future submitters to emulate. > I assume what you're trying to do here is to make the > version-related failures more explicit, rather than have users > parse an ImportError traceback, e.g. See above. At least half the point is making our dependencies explicit rather than implicit, so we can make better policy decisions. > But what about the high-end of the version range? I'm pretty > sure most of these scripts will throw syntax errors on >= 3.0, > how should we catch that before users see it? That's a problem for another day, when 3.x is more widely deployed. I'd be willing to run 2to3 on these scripts and check forward compatibility. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html