You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Hett <st...@egosoft.com> on 2015/07/20 16:59:08 UTC
[PATCH] Error out with proper error message when using Python >= 3.0
(was: building SVN trunk on Windows fails on python gen-make.py)
> [ moved from users@ to dev@; tldr: trunk gen-make.py fails with py3.4/windows ]
>
> Stefan Hett wrote on Mon, Jun 22, 2015 at 15:12:31 +0200:
>>> On Mon, Jun 22, 2015 at 12:45 PM, Stefan Hett <st...@egosoft.com> wrote:
>>>> File "E:\Python34\lib\encodings\cp1252.py", line 23, in decode return
>>>> codecs.charmap_decode(input,self.errors,decoding_table)[0]
>>>> UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2116:
>>>> character maps to <undefined>
>>> Quick shot: perhaps it's related to the Python version. I'm using
>>> Python 2.7. Can you try that?
>>>
>> Hi Johan,
>>
>> thanks for the hint. That indeed seemed to have been the problem.
>> Passes through the python script now when using Python 2.7.10.
>>
>> Regards,
>> Stefan
> Two things about that error:
>
> 1. The file that triggers it is probably
> subversion/tests/cmdline/upgrade_tests_data/upgrade_with_externals.tar.bz2
> (it has a 0x81 byte at the given offset). It's a binary file so it
> shouldn't be fed to a unicode decoder in the first place. It's only
> used by some unit tests.
>
> 2. I went through autogen.sh/configure on Python 3 on Linux a few weeks
> ago and got it to pass. (I don't recall what's the status of the test
> suite under py3.) So either this issue is specific to Py3 on Windows,
> or I missed something, or the gen-make.py code has changed.
>
> Anyway, gen-make.py shouldn't fail like that. I'd rather it just worked
> under py3, but if we can't make it work, we should error out up front if
> Python is newer than we support.
Given there's been not much progress on the issue, I quickly
put-together (and tested) a patch to detect Python >= 3 and issue a
user-readable error. Maybe it'd be worth including this in 1.9, so
people trying to build 1.9 don't have to go through the hazzle of
figuring out that the problem is their current python-version rather
than some other problem?
Please note that while testing I also found 1.7/1.8 not working with
Python 3.4.3 as well. Error (in both cases):
File "gen-make.py", line 271
except getopt.GetoptError, e:
^
SyntaxError: invalid syntax
So I guess it might be worthwhile adding some check there too?
[[[
Detect Python >= 3.0 and error out in gen-make.py (rather than
producing some cryptic error/callstack).
* gen-make.py
(): Add python version check >= 3.0 and error out.
]]]
Regards,
Stefan
Re: 1.9.0 minimal Python version
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Fri, Jul 24, 2015 at 14:13:04 +0100:
> Philip Martin <ph...@wandisco.com> writes:
>
> > Philip Martin <ph...@wandisco.com> writes:
> >
> >> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
> >> available as a Red Hat Software Collection component.
> >
> > The Software Collection python27 is sufficient to build Subversion and
> > run the regression tests but some of the tests FAIL. The tests that
> > fail all install a python hook script and the hook script fails to run.
> > The reason is that the Software Collection relies on setting environment
> > variables to make the Python 2.7 binary and libraries available but
> > Subversion cleans the environment before running hooks.
>
> If tried using a script
>
> #!/bin/sh
> LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64:$LD_LIBRARY_PATH /opt/rh/python27/root/usr/bin/python "$@"
>
> but it doesn't fix the FAILs as the hook scripts have an explict
>
> #!/opt/rh/python27/root/usr/bin/python
>
> The PYTHON setting in the Makefile is the path to the script and this is
> what we want in the hook.
You could fix that by making your wrapper script set Python's argv[0]
(at the C level) to the absolute path to the wrapper script. That'll
cause Python's sys.executable to be the wrapper script, which will make
the test harness write the path to the wrapper script in the #! line.
> We have a related, but sort of opposite, problem with parallel tests. I
> can use the script even if it is not found in PATH by doing:
>
> PYTHON=/path/to/script ./autogen.sh
> PYTHON=/path/to/script ./configure
> make check
>
> and the tests run (with the hook tests failing). If I attempt to run
> the tests in parallel
>
> make check PARALLEL=1
>
> then all the python tests SKIP because when the parallel code spawns
> additional python it uses the python found in PATH rather than the
> Makefile PYTHON.
IMO that's a bug, we shouldn't use the PATH python for subprocesses. We
should probably make the PARALLEL codepath use imp.load_module() like
run_tests() uses.
>
Cheers,
Daniel
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Philip Martin <ph...@wandisco.com> writes:
>
>> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
>> available as a Red Hat Software Collection component.
>
> The Software Collection python27 is sufficient to build Subversion and
> run the regression tests but some of the tests FAIL. The tests that
> fail all install a python hook script and the hook script fails to run.
> The reason is that the Software Collection relies on setting environment
> variables to make the Python 2.7 binary and libraries available but
> Subversion cleans the environment before running hooks.
If tried using a script
#!/bin/sh
LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64:$LD_LIBRARY_PATH /opt/rh/python27/root/usr/bin/python "$@"
but it doesn't fix the FAILs as the hook scripts have an explict
#!/opt/rh/python27/root/usr/bin/python
The PYTHON setting in the Makefile is the path to the script and this is
what we want in the hook.
We have a related, but sort of opposite, problem with parallel tests. I
can use the script even if it is not found in PATH by doing:
PYTHON=/path/to/script ./autogen.sh
PYTHON=/path/to/script ./configure
make check
and the tests run (with the hook tests failing). If I attempt to run
the tests in parallel
make check PARALLEL=1
then all the python tests SKIP because when the parallel code spawns
additional python it uses the python found in PATH rather than the
Makefile PYTHON.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
> available as a Red Hat Software Collection component.
The Software Collection python27 is sufficient to build Subversion and
run the regression tests but some of the tests FAIL. The tests that
fail all install a python hook script and the hook script fails to run.
The reason is that the Software Collection relies on setting environment
variables to make the Python 2.7 binary and libraries available but
Subversion cleans the environment before running hooks.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> [please do not top-post]
>
> On 24.07.2015 11:00, Stefan Hett wrote:
>> In case that helps with the decision making process:
>> Debian 5.0 (lenny - no longer supported): py 2.5
>> Debian 6.0 (squeeze - current oldoldstable): py2.6
>> Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
>> oldstable/stable/testing): py2.7
>
> The "very old enterprise versions" are probably RHEL 6 and SuSE 10; both
> are still in wide use.
RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
available as a Red Hat Software Collection component.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
[please do not top-post]
On 24.07.2015 11:00, Stefan Hett wrote:
> In case that helps with the decision making process:
> Debian 5.0 (lenny - no longer supported): py 2.5
> Debian 6.0 (squeeze - current oldoldstable): py2.6
> Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
> oldstable/stable/testing): py2.7
The "very old enterprise versions" are probably RHEL 6 and SuSE 10; both
are still in wide use.
> So even this very conservative Linux distribution is supporting py2.7
> for the past two years (and with the backporting branch I assume even
> squeeze supports 2.7 which would make it a supported platform for the
> pat 4 years on that distribution).
>
> Source:
> https://packages.debian.org/search?keywords=python&searchon=names&suite=all§ion=all
>> On 23.07.2015 17:01, Bert Huijben wrote:
>>> I like this proposal... but I'm wondering in what case Linux build
>>> environments need python. Those very old enterprise versions are
>>> unlikely to have python 2.7 or newer.
>>
>> When building from a tarball, you only need Python to run the test suite.
>>
>> There are certain edge cases in the Python syntax where it's almost
>> impossible to be compatible with both 2.5/2.6 and 3.x. Because of
>> that, and because 2.6 is no longer supporter by the Python devs, it
>> makes sense to stop supporting those versions in 1.9/trunk.
>>
>> Those very old enterprise versions will just have to be upgraded, IMO.
>>
>>
>>> ------------------------------------------------------------------------
>>> From: Branko Čibej <ma...@wandisco.com>
>>> Sent: 23-7-2015 11:02
>>> To: dev@subversion.apache.org
>>> Subject: Re: 1.9.0 minimal Python version
>>>
>>> On 23.07.2015 10:30, Stefan Hett wrote:
>>> > Hi,
>>> >
>>> >>>> - For 1.9, it's a little late to make any changes, but I would
>>> >>>> consider
>>> >>>> dropping py2.5 support (and converting to the 'except' 'as'
>>> >>>> syntax),
>>> >>>> since for 1.9 py3 support is more important than py2.5 support.
>>> >>>>
>>> >>>> Thoughts?
>>> >> I'd rather not mess with the 1.9 branch at this point ... we're
>>> so close
>>> >> to the release (I hope).
>>> >>
>>> >> -- Brane
>>> > as a thought for the 1.9 case:
>>> > In case you do not want to drop py2.5 support for 1.9 because it's
>>> > released stating that minimum support already, would it be an option
>>> > to still support py3 in a following patch (1.9.1)? For instance by
>>> > providing py-script versions for older as well as later versions?
>>> >
>>> > Reasoning would be that given that SVN-versions have a lifetime of
>>> > roughly 2 years before the successive version is released it'd be
>>> > quite a limitation if that'd only work with a very old python
>>> version...
>>> >
>>> > As an alternative approach: You'd also consider mentioning a minimum
>>> > requirement of python 2.6 just in the docs (no code changes yet) and
>>> > then release 1.9.1 with the actual "fixes". So technically then even
>>> > post release you would not change the minimal system requirements.
>>> >
>>> > (just some thoughts from a user's point of view, if that input would
>>> > be of any benefit)
>>>
>>> Daniel and I have just been chatting about this on IRC, and we agreed
>>> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
>>> proposal is that we declare support for 2.7, and at some point make
>>> 1.9.x and trunk compatible with both 2.7 and 3.x.
>>>
>>> -- Brane
>>
>
Re: 1.9.0 minimal Python version
Posted by Stefan Hett <st...@egosoft.com>.
In case that helps with the decision making process:
Debian 5.0 (lenny - no longer supported): py 2.5
Debian 6.0 (squeeze - current oldoldstable): py2.6
Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
oldstable/stable/testing): py2.7
So even this very conservative Linux distribution is supporting py2.7
for the past two years (and with the backporting branch I assume even
squeeze supports 2.7 which would make it a supported platform for the
pat 4 years on that distribution).
Source:
https://packages.debian.org/search?keywords=python&searchon=names&suite=all§ion=all
> On 23.07.2015 17:01, Bert Huijben wrote:
>> I like this proposal... but I'm wondering in what case Linux build
>> environments need python. Those very old enterprise versions are
>> unlikely to have python 2.7 or newer.
>
> When building from a tarball, you only need Python to run the test suite.
>
> There are certain edge cases in the Python syntax where it's almost
> impossible to be compatible with both 2.5/2.6 and 3.x. Because of
> that, and because 2.6 is no longer supporter by the Python devs, it
> makes sense to stop supporting those versions in 1.9/trunk.
>
> Those very old enterprise versions will just have to be upgraded, IMO.
>
>
>> ------------------------------------------------------------------------
>> From: Branko Čibej <ma...@wandisco.com>
>> Sent: 23-7-2015 11:02
>> To: dev@subversion.apache.org <ma...@subversion.apache.org>
>> Subject: Re: 1.9.0 minimal Python version
>>
>> On 23.07.2015 10:30, Stefan Hett wrote:
>> > Hi,
>> >
>> >>>> - For 1.9, it's a little late to make any changes, but I would
>> >>>> consider
>> >>>> dropping py2.5 support (and converting to the 'except' 'as'
>> >>>> syntax),
>> >>>> since for 1.9 py3 support is more important than py2.5 support.
>> >>>>
>> >>>> Thoughts?
>> >> I'd rather not mess with the 1.9 branch at this point ... we're so
>> close
>> >> to the release (I hope).
>> >>
>> >> -- Brane
>> > as a thought for the 1.9 case:
>> > In case you do not want to drop py2.5 support for 1.9 because it's
>> > released stating that minimum support already, would it be an option
>> > to still support py3 in a following patch (1.9.1)? For instance by
>> > providing py-script versions for older as well as later versions?
>> >
>> > Reasoning would be that given that SVN-versions have a lifetime of
>> > roughly 2 years before the successive version is released it'd be
>> > quite a limitation if that'd only work with a very old python
>> version...
>> >
>> > As an alternative approach: You'd also consider mentioning a minimum
>> > requirement of python 2.6 just in the docs (no code changes yet) and
>> > then release 1.9.1 with the actual "fixes". So technically then even
>> > post release you would not change the minimal system requirements.
>> >
>> > (just some thoughts from a user's point of view, if that input would
>> > be of any benefit)
>>
>> Daniel and I have just been chatting about this on IRC, and we agreed
>> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
>> proposal is that we declare support for 2.7, and at some point make
>> 1.9.x and trunk compatible with both 2.7 and 3.x.
>>
>> -- Brane
>
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 17:01, Bert Huijben wrote:
> I like this proposal... but I'm wondering in what case Linux build
> environments need python. Those very old enterprise versions are
> unlikely to have python 2.7 or newer.
When building from a tarball, you only need Python to run the test suite.
There are certain edge cases in the Python syntax where it's almost
impossible to be compatible with both 2.5/2.6 and 3.x. Because of that,
and because 2.6 is no longer supporter by the Python devs, it makes
sense to stop supporting those versions in 1.9/trunk.
Those very old enterprise versions will just have to be upgraded, IMO.
> ------------------------------------------------------------------------
> From: Branko Čibej <ma...@wandisco.com>
> Sent: 23-7-2015 11:02
> To: dev@subversion.apache.org <ma...@subversion.apache.org>
> Subject: Re: 1.9.0 minimal Python version
>
> On 23.07.2015 10:30, Stefan Hett wrote:
> > Hi,
> >
> >>>> - For 1.9, it's a little late to make any changes, but I would
> >>>> consider
> >>>> dropping py2.5 support (and converting to the 'except' 'as'
> >>>> syntax),
> >>>> since for 1.9 py3 support is more important than py2.5 support.
> >>>>
> >>>> Thoughts?
> >> I'd rather not mess with the 1.9 branch at this point ... we're so
> close
> >> to the release (I hope).
> >>
> >> -- Brane
> > as a thought for the 1.9 case:
> > In case you do not want to drop py2.5 support for 1.9 because it's
> > released stating that minimum support already, would it be an option
> > to still support py3 in a following patch (1.9.1)? For instance by
> > providing py-script versions for older as well as later versions?
> >
> > Reasoning would be that given that SVN-versions have a lifetime of
> > roughly 2 years before the successive version is released it'd be
> > quite a limitation if that'd only work with a very old python version...
> >
> > As an alternative approach: You'd also consider mentioning a minimum
> > requirement of python 2.6 just in the docs (no code changes yet) and
> > then release 1.9.1 with the actual "fixes". So technically then even
> > post release you would not change the minimal system requirements.
> >
> > (just some thoughts from a user's point of view, if that input would
> > be of any benefit)
>
> Daniel and I have just been chatting about this on IRC, and we agreed
> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
> proposal is that we declare support for 2.7, and at some point make
> 1.9.x and trunk compatible with both 2.7 and 3.x.
>
> -- Brane
RE: 1.9.0 minimal Python version
Posted by Bert Huijben <be...@qqmail.nl>.
I like this proposal... but I'm wondering in what case Linux build environments need python. Those very old enterprise versions are unlikely to have python 2.7 or newer.
Bert
-----Original Message-----
From: "Branko Čibej" <br...@wandisco.com>
Sent: 23-7-2015 11:02
To: "dev@subversion.apache.org" <de...@subversion.apache.org>
Subject: Re: 1.9.0 minimal Python version
On 23.07.2015 10:30, Stefan Hett wrote:
> Hi,
>
>>>> - For 1.9, it's a little late to make any changes, but I would
>>>> consider
>>>> dropping py2.5 support (and converting to the 'except' 'as'
>>>> syntax),
>>>> since for 1.9 py3 support is more important than py2.5 support.
>>>>
>>>> Thoughts?
>> I'd rather not mess with the 1.9 branch at this point ... we're so close
>> to the release (I hope).
>>
>> -- Brane
> as a thought for the 1.9 case:
> In case you do not want to drop py2.5 support for 1.9 because it's
> released stating that minimum support already, would it be an option
> to still support py3 in a following patch (1.9.1)? For instance by
> providing py-script versions for older as well as later versions?
>
> Reasoning would be that given that SVN-versions have a lifetime of
> roughly 2 years before the successive version is released it'd be
> quite a limitation if that'd only work with a very old python version...
>
> As an alternative approach: You'd also consider mentioning a minimum
> requirement of python 2.6 just in the docs (no code changes yet) and
> then release 1.9.1 with the actual "fixes". So technically then even
> post release you would not change the minimal system requirements.
>
> (just some thoughts from a user's point of view, if that input would
> be of any benefit)
Daniel and I have just been chatting about this on IRC, and we agreed
that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
proposal is that we declare support for 2.7, and at some point make
1.9.x and trunk compatible with both 2.7 and 3.x.
-- Brane
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 10:30, Stefan Hett wrote:
> Hi,
>
>>>> - For 1.9, it's a little late to make any changes, but I would
>>>> consider
>>>> dropping py2.5 support (and converting to the 'except' 'as'
>>>> syntax),
>>>> since for 1.9 py3 support is more important than py2.5 support.
>>>>
>>>> Thoughts?
>> I'd rather not mess with the 1.9 branch at this point ... we're so close
>> to the release (I hope).
>>
>> -- Brane
> as a thought for the 1.9 case:
> In case you do not want to drop py2.5 support for 1.9 because it's
> released stating that minimum support already, would it be an option
> to still support py3 in a following patch (1.9.1)? For instance by
> providing py-script versions for older as well as later versions?
>
> Reasoning would be that given that SVN-versions have a lifetime of
> roughly 2 years before the successive version is released it'd be
> quite a limitation if that'd only work with a very old python version...
>
> As an alternative approach: You'd also consider mentioning a minimum
> requirement of python 2.6 just in the docs (no code changes yet) and
> then release 1.9.1 with the actual "fixes". So technically then even
> post release you would not change the minimal system requirements.
>
> (just some thoughts from a user's point of view, if that input would
> be of any benefit)
Daniel and I have just been chatting about this on IRC, and we agreed
that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
proposal is that we declare support for 2.7, and at some point make
1.9.x and trunk compatible with both 2.7 and 3.x.
-- Brane
Re: 1.9.0 minimal Python version
Posted by Stefan Hett <st...@egosoft.com>.
Hi,
>>> - For 1.9, it's a little late to make any changes, but I would consider
>>> dropping py2.5 support (and converting to the 'except' 'as' syntax),
>>> since for 1.9 py3 support is more important than py2.5 support.
>>>
>>> Thoughts?
> I'd rather not mess with the 1.9 branch at this point ... we're so close
> to the release (I hope).
>
> -- Brane
as a thought for the 1.9 case:
In case you do not want to drop py2.5 support for 1.9 because it's
released stating that minimum support already, would it be an option to
still support py3 in a following patch (1.9.1)? For instance by
providing py-script versions for older as well as later versions?
Reasoning would be that given that SVN-versions have a lifetime of
roughly 2 years before the successive version is released it'd be quite
a limitation if that'd only work with a very old python version...
As an alternative approach: You'd also consider mentioning a minimum
requirement of python 2.6 just in the docs (no code changes yet) and
then release 1.9.1 with the actual "fixes". So technically then even
post release you would not change the minimal system requirements.
(just some thoughts from a user's point of view, if that input would be
of any benefit)
Regards,
Stefan
Re: 1.9.0 minimal Python version (was: Re: [PATCH] Error out with
proper error message when using Python >= 3.0
Posted by Branko Čibej <br...@wandisco.com>.
On 22.07.2015 13:46, Daniel Shahaf wrote:
> [Re-sending with a new subject to draw attention to the 1.9 question.]
>
> Daniel Shahaf wrote on Wed, Jul 22, 2015 at 11:31:31 +0000:
>> Stefan Hett wrote on Mon, Jul 20, 2015 at 16:59:08 +0200:
>>> Please note that while testing I also found 1.7/1.8 not working with
>>> Python 3.4.3 as well. Error (in both cases):
>>> File "gen-make.py", line 271
>>> except getopt.GetoptError, e:
>>> ^
>>> SyntaxError: invalid syntax
>>>
>> The 'except' comma syntax is supported by Python through 2.7 (inclusive)
>> and the 'except' 'as' syntax is supported by Python 2.6 and newer.
>> Currently, trunk advertises support for Python 2.5 and newer (so, in
>> particular, so do the older branches).
>>
>> So, I think we should:
>>
>> - For 1.7/1.8, if we expect people will try to build them with py3,
>> we can apply the patch. (The patch is correct; we must remain
>> compatible with py2.5 on those branches; and we can't easily be
>> compatible with py3 at the same time.)
Ack.
>> - For trunk, I think we should convert to the 'except' 'as' syntax and
>> drop py2.5 support. (Actually, we could drop py2.6 support as well,
>> as py2.6 has been EOL for nearly two years now.)
Ack.
>> - For 1.9, it's a little late to make any changes, but I would consider
>> dropping py2.5 support (and converting to the 'except' 'as' syntax),
>> since for 1.9 py3 support is more important than py2.5 support.
>>
>> Thoughts?
I'd rather not mess with the 1.9 branch at this point ... we're so close
to the release (I hope).
-- Brane
>> References:
>>
>> [py2.5 'except' syntax] https://docs.python.org/2.5/ref/try.html
>> [py2.6 'except' syntax] https://docs.python.org/2.6/reference/compound_stmts.html#the-try-statement
>> [py2.6 EOL] https://www.python.org/dev/peps/pep-0361/
>>
>>> So I guess it might be worthwhile adding some check there too?
>>>
>>> [[[
>>> Detect Python >= 3.0 and error out in gen-make.py (rather than
>>> producing some cryptic error/callstack).
>>>
>>> * gen-make.py
>>> (): Add python version check >= 3.0 and error out.
>>> ]]]
1.9.0 minimal Python version (was: Re: [PATCH] Error out with proper
error message when using Python >= 3.0 (was: building SVN trunk on Windows
fails on python gen-make.py))
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[Re-sending with a new subject to draw attention to the 1.9 question.]
Daniel Shahaf wrote on Wed, Jul 22, 2015 at 11:31:31 +0000:
> Stefan Hett wrote on Mon, Jul 20, 2015 at 16:59:08 +0200:
> > Please note that while testing I also found 1.7/1.8 not working with
> > Python 3.4.3 as well. Error (in both cases):
> > File "gen-make.py", line 271
> > except getopt.GetoptError, e:
> > ^
> > SyntaxError: invalid syntax
> >
>
> The 'except' comma syntax is supported by Python through 2.7 (inclusive)
> and the 'except' 'as' syntax is supported by Python 2.6 and newer.
> Currently, trunk advertises support for Python 2.5 and newer (so, in
> particular, so do the older branches).
>
> So, I think we should:
>
> - For 1.7/1.8, if we expect people will try to build them with py3,
> we can apply the patch. (The patch is correct; we must remain
> compatible with py2.5 on those branches; and we can't easily be
> compatible with py3 at the same time.)
>
> - For trunk, I think we should convert to the 'except' 'as' syntax and
> drop py2.5 support. (Actually, we could drop py2.6 support as well,
> as py2.6 has been EOL for nearly two years now.)
>
> - For 1.9, it's a little late to make any changes, but I would consider
> dropping py2.5 support (and converting to the 'except' 'as' syntax),
> since for 1.9 py3 support is more important than py2.5 support.
>
> Thoughts?
>
> Daniel
>
> --
>
> References:
>
> [py2.5 'except' syntax] https://docs.python.org/2.5/ref/try.html
> [py2.6 'except' syntax] https://docs.python.org/2.6/reference/compound_stmts.html#the-try-statement
> [py2.6 EOL] https://www.python.org/dev/peps/pep-0361/
>
> > So I guess it might be worthwhile adding some check there too?
> >
> > [[[
> > Detect Python >= 3.0 and error out in gen-make.py (rather than
> > producing some cryptic error/callstack).
> >
> > * gen-make.py
> > (): Add python version check >= 3.0 and error out.
> > ]]]
Re: [PATCH] Error out with proper error message when using Python >=
3.0 (was: building SVN trunk on Windows fails on python gen-make.py)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Hett wrote on Mon, Jul 20, 2015 at 16:59:08 +0200:
> Please note that while testing I also found 1.7/1.8 not working with
> Python 3.4.3 as well. Error (in both cases):
> File "gen-make.py", line 271
> except getopt.GetoptError, e:
> ^
> SyntaxError: invalid syntax
>
The 'except' comma syntax is supported by Python through 2.7 (inclusive)
and the 'except' 'as' syntax is supported by Python 2.6 and newer.
Currently, trunk advertises support for Python 2.5 and newer (so, in
particular, so do the older branches).
So, I think we should:
- For 1.7/1.8, if we expect people will try to build them with py3,
we can apply the patch. (The patch is correct; we must remain
compatible with py2.5 on those branches; and we can't easily be
compatible with py3 at the same time.)
- For trunk, I think we should convert to the 'except' 'as' syntax and
drop py2.5 support. (Actually, we could drop py2.6 support as well,
as py2.6 has been EOL for nearly two years now.)
- For 1.9, it's a little late to make any changes, but I would consider
dropping py2.5 support (and converting to the 'except' 'as' syntax),
since for 1.9 py3 support is more important than py2.5 support.
Thoughts?
Daniel
--
References:
[py2.5 'except' syntax] https://docs.python.org/2.5/ref/try.html
[py2.6 'except' syntax] https://docs.python.org/2.6/reference/compound_stmts.html#the-try-statement
[py2.6 EOL] https://www.python.org/dev/peps/pep-0361/
> So I guess it might be worthwhile adding some check there too?
>
> [[[
> Detect Python >= 3.0 and error out in gen-make.py (rather than
> producing some cryptic error/callstack).
>
> * gen-make.py
> (): Add python version check >= 3.0 and error out.
> ]]]
>
> Regards,
> Stefan
> Index: gen-make.py
> ===================================================================
> --- gen-make.py (revision 1691913)
> +++ gen-make.py (working copy)
> @@ -28,6 +28,10 @@
> import traceback
> import sys
>
> +if sys.hexversion >= 0x03000000:
> + print("Python >= 3.0 not supported. Please use Python >= 2.5 and < 3.0")
> + sys.exit(2)
> +
> import getopt
> try:
> my_getopt = getopt.gnu_getopt