Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines

[John Keeping <john@keeping.me.uk>]

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