Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2013, 19:04 UTC
Message-ID: <7vvcauqpn4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130118180639.GD31172@serenity.lan>

John Keeping <john@keeping.me.uk> writes:

Show 19 quoted lines

> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 69f7e9b..baf3b41 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -179,6 +179,22 @@ 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.  In this case we use
> +   `from __future__ import unicode_literals` if we need to differentiate
> +   Unicode string literals, rather than prefixing Unicode strings with
> +   'u' since the latter is not supported in Python versions 3.0 - 3.2.

"In this case"? In what case? This document will stay effective long after you settle one particular backward incompatibility Python 3 introduced, namely, the unicode literal issues. It is just one "example".

That example somehow tells me that early versions of Python 3.x series may be too buggy and not worth worrying about, and we may want to set a floor for Python 3.x series, too, with something like:

    - The code should be compatible with 2.6 and newer versions of
      Python 2.x series; 2.5 and older are not supported anymore.

    - The code should also be comptabile with 3.2 and newer versions
      of Python 3.x series; 3.1 and older are not mature enough and
      have too many problems to write scripts that work on it and
      solid 2.x at the same time.

I am not actively advocating to disqualify early 3.x; I am just suggesting that doing so may be a viable escape hatch for us that does not harm real users. If you and others who know Python better think there isn't any problem that makes it too cumbersome to support both late 2.x and 3.0/3.1, there is no reason to set the floor at 3.2.

I just have this feeling that we might be better off treating them as 0.x releases of a new software called Python3, that happens to be similar to the Python we know.