You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2015/02/13 11:25:26 UTC

Minimum Python requirement for autogen.sh?

The attached patch makes autogen.sh support Python 3.  However, it
increases the minimal Python requirement from 2.5 to 2.6 for people who
run autogen.sh or build on Windows.  The minimum Python required for
'make check' on Unix is unaffected and remains 2.5.

Python 2.6 was released in 2008, aka, when Subversion 1.5.2 was current.

Okay to bump the minimum?

Daniel

P.S. I didn't test with Python 2.6 since I didn't have a copy handy, but
I tested with 2.7 and confirmed via Python's online docs that the
requisite syntax and library interfaces had been introduced in 2.6.

RE: Minimum Python requirement for autogen.sh?

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: vrijdag 13 februari 2015 11:25
> To: dev@subversion.apache.org
> Subject: Minimum Python requirement for autogen.sh?
> 
> The attached patch makes autogen.sh support Python 3.  However, it
> increases the minimal Python requirement from 2.5 to 2.6 for people who
> run autogen.sh or build on Windows.  The minimum Python required for
> 'make check' on Unix is unaffected and remains 2.5.
> 
> Python 2.6 was released in 2008, aka, when Subversion 1.5.2 was current.
> 
> Okay to bump the minimum?

Your patch changes subversion/tests/libsvn_subr/subst_translate-test.c ?

RE:
[[
+# TODO: The makefile generator opens our source files in text mode, which
+# depends on the locale.  We should either set the locale to a known value,
+# or teach the makefile generator to open source files as UTF-8 text
+# regardless of locale.
]]

So does the C compiler, so I don't really see a problem.

There shouldn't be unescaped high 'ascii' in our source files.

	Bert
> 
> Daniel
> 
> P.S. I didn't test with Python 2.6 since I didn't have a copy handy, but
> I tested with 2.7 and confirmed via Python's online docs that the
> requisite syntax and library interfaces had been introduced in 2.6.


Re: Minimum Python requirement for autogen.sh?

Posted by Branko Čibej <br...@wandisco.com>.
On 13.02.2015 11:25, Daniel Shahaf wrote:
> The attached patch makes autogen.sh support Python 3.  However, it
> increases the minimal Python requirement from 2.5 to 2.6 for people who
> run autogen.sh or build on Windows.  The minimum Python required for
> 'make check' on Unix is unaffected and remains 2.5.
>
> Python 2.6 was released in 2008, aka, when Subversion 1.5.2 was current.
>
> Okay to bump the minimum?
[...]
> Index: build/generator/gen_base.py
> =======================================
> --- build/generator/gen_base.py	(revision 1659491)
> +++ build/generator/gen_base.py	(working copy)
> @@ -248,12 +248,12 @@
> class GeneratorBase:
> """
> try:
> - old_contents = open(fname, 'rb').read()
> + old_contents = open(fname, 'r').read()
> except IOError:
> old_contents = None
> if old_contents != new_contents:
> - open(fname, 'wb').write(new_contents)
> + open(fname, 'w').write(new_contents)
> print("Wrote: %s" % fname)

I don't understand this change. We read and write the files in binary
mode because we don't want to bother with encoding conversions.
Incidentally, this removes the ability to generate makefiles on Windows,
because it will write them with \r\n line endings that make doesn't like.

Is it a problem with the str()/unicode()/bytes() incompatibility? If it
is, the ezt template generator will have fun with those, too; even
though we shouldn't have any non-ASCII characters in the templates, nor
in the generated makefiles or .vc(x)proj files.

> Index: build/getversion.py
> =======================================
> --- build/getversion.py	(revision 1659491)
> +++ build/getversion.py	(working copy)
> @@ -64,8 +64,8 @@
> def svn_extractor(parser, include_file):
> try:
> r = p.parse(include_file)
> - except IOError, e:
> + except IOError as e:
> usage_and_exit(str(e))
> sys.stdout.write("%d.%d.%d" % (r.major, r.minor, r.patch))

This can be rewritten as:

    except IOError:
      typ, val, tb = sys.exc_info()
      usage_and_exit(traceback.format_exception_only(tp, val))

which will work on older Python versions, too. (Of course you need to
import the traceback module in the file). Same for the other two instances.

> Index: build/transform_sql.py
> =======================================
> --- build/transform_sql.py	(revision 1659491)
> +++ build/transform_sql.py	(working copy)
> @@ -194,8 +194,8 @@
> class Processor(object):
> line)
> # Another preprocessing.
> - for symbol, string in self.token_map.iteritems():
> + for symbol, string in self.token_map.items():
> # ### This doesn't sql-escape 'string'
> line = re.sub(r'\b%s\b' % re.escape(symbol), "'%s'" % string, line)

OK; will work with older Python versions, it just won't be as efficient
because .items() creates a list in 2.x. Running this with Python 2.x
will use more memory, but it shouldn't be excessive.

> +# TODO: The makefile generator opens our source files in text mode,
> which
> +# depends on the locale. We should either set the locale to a known
> value,
> +# or teach the makefile generator to open source files as UTF-8 text
> +# regardless of locale.

As Bert said, we shouldn't have non-ASCII characters in our sources.
Which brings us to ...

> Index: subversion/tests/libsvn_subr/subst_translate-test.c
> =======================================
> --- subversion/tests/libsvn_subr/subst_translate-test.c	(revision 1659491)
> +++ subversion/tests/libsvn_subr/subst_translate-test.c	(working copy)
> @@ -115,8 +115,8 @@
> test_svn_subst_translate_string2_null_encoding_hel
> svn_string_t *new_value = NULL;
> svn_boolean_t translated_to_utf8 = FALSE;
> svn_boolean_t translated_line_endings = TRUE;
> - /* '�', which is 0xc6 in both ISO-8859-1 and Windows-1252 */
> + /* 'Æ', which is 0xc6 in both ISO-8859-1 and Windows-1252 */
> svn_string_t *source_string = svn_string_create("\xc6", pool);

... rewriting the comment to not contain the Æ ligature but to spell it
out instead; e.g.

    /* The 'AE' ligature, which is 0xc6 .... */


-- Brane