From: John Keeping Date: Wed, 30 Jan 2013 20:31:58 GMT Subject: Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines Message-ID: <20130130203158.GN1342@serenity.lan> In-Reply-To: <5108F056.9040406@alum.mit.edu> On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: > Nit: s/it is supported/it has been supported/ Thanks, I'll fix in the re-roll. > I think this would be a good Python policy. > > I would hate to junk up all Python code with things like > > ' '.encode('ascii') > > though, so maybe we should establish a small Python library of > compatibility utilities (like a small "six"). It could contain b(). > > Another handy utility function could be > > def check_python_version(minimum_v2=0x02060000, > minimum_v3=0x03010000) > > which checks our default Python requirements by default, but is > overrideable by specific scripts if they know that they can deal with > older Python versions. > > But I haven't had time to think of where to put such a library, how to > install it, etc. If we want to go that route, I think restructuring the "git_remote_helpers" directory and re-using its infrastructure for installing the "Git Python modules" would be the way to go. The directory structure would become something like this: git/ `-- python/ |-- Makefile # existing file pulled out of git_remote_helpers |-- < some new utility library > |-- git_remote_helpers | |-- __init__.py | |-- git | | |-- __init__.py | | |-- exporter.py | | |-- git.py | | |-- importer.py | | |-- non_local.py | | `-- repo.py | `-- util.py |-- setup.cfg # existing file pulled out of git_remote_helpers `-- setup.py # existing file pulled out of git_remote_helpers It looks like the GitPython project[1] as already taken the "git" module name, so perhaps we should use "git_core" if we do introduce a new module. [1] http://pypi.python.org/pypi/GitPython John