git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jan 30, 2013, 10:05 UTC
Message-ID
<5108F056.9040406@alum.mit.edu>
In-Reply-To
<20130129190844.GB1342@serenity.lan>
On 01/29/2013 08:08 PM, John Keeping wrote:
Show 74 quoted lines
> These are kept short by simply deferring to PEP-8.  Most of the Python
> code in Git is already very close to this style (some things in contrib/
> are not).
> 
> Rationale for version suggestions:
> 
>  - Amongst the noise in [1], there isn't any disagreement about using
>    2.6 as a base (see also [2]), although Brandon Casey recently added
>    support for 2.4 and 2.5 to git-p4 [3].
> 
>  - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
>    significantly easier [4].
> 
>  - Advocating Python 3 support in all scripts is currently unrealistic
>    because:
> 
>      - 'p4 -G' provides output in a format that is very hard to use with
>        Python 3 (and its documentation claims Python 3 is unsupported).
> 
>      - Mercurial does not support Python 3.
> 
>      - Bazaar does not support Python 3.
> 
>  - But we should try to make new scripts compatible with Python 3
>    because all new Python development is happening on version 3 and the
>    Python community will eventually stop supporting Python 2 [5].
> 
>  - Python 3.1 is required to support the 'surrogateescape' error handler
>    for encoding/decodng filenames to/from Unicode strings and Python 3.0
>    is not longer supported.
> 
> [1] http://thread.gmane.org/gmane.comp.version-control.git/210329
> [2] http://article.gmane.org/gmane.comp.version-control.git/210429
> [3] http://thread.gmane.org/gmane.comp.version-control.git/214579
> [4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
> [5] http://www.python.org/dev/peps/pep-0404/
> 
> ---
> Changes since v1:
> 
> - Set 3.1 as the minimum Python 3 version
> 
> - Remove the section on Unicode literals - it just adds confusion and
>   doesn't apply to the current code; we can deal with any issues if they
>   ever arise.
> 
>  Documentation/CodingGuidelines | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 69f7e9b..db7a416 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -179,6 +179,19 @@ For C programs:
>   - Use Git's gettext wrappers to make the user interface
>     translatable. See "Marking strings for translation" in po/README.
>  
> +For Python scripts:
> +
> + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
> +
> + - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
> +
> + - Where required libraries do not restrict us to Python 2, we try to
> +   also be compatible with Python 3.1 and later.
> +
> + - We use the 'b' prefix for bytes literals.  Note that even though
> +   the Python documentation for version 2.6 does not mention this
> +   prefix it is supported since version 2.6.0.
> +
>  Writing Documentation:
>  
>   Every user-visible change should be reflected in the documentation.
> 
Nit: s/it is supported/it has been supported/
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.

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: John KeepingNext: John Keeping
Message 4 of 8 in “CodingGuidelines: add Python coding guidelines”
  1. CodingGuidelines: add Python coding guidelinesJohn Keeping, Jan 29, 2013
  2. Junio C HamanoJan 29, 2013
  3. John KeepingJan 29, 2013
  4. Michael HaggertyJan 30, 2013
  5. John KeepingJan 30, 2013
  6. Michael HaggertyFeb 1, 2013
  7. John KeepingFeb 1, 2013
  8. Pete WyckoffFeb 3, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.