homepage

Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version
The format of sys.version now start with a version number and (
2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
File: Lib\platform.py
Function: def _sys_version(sys_version=None):
Line: 1326

Frederic Torres wrote:
> 
> New submission from Frederic Torres <fredericaltorres@gmail.com>:
> 
> Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version
> 
> The format of sys.version now start with a version number and (
> 2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
> 
> File: Lib\platform.py
> Function: def _sys_version(sys_version=None):
> Line: 1326
I assume you meant: doesn't correctly parse the version number.
Could you provide a complete example formatted as Python string,
e.g. print repr(sys.version) ?!
Thanks,
-- 
Marc-Andre Lemburg
eGenix.com
________________________________________________________________________
2010年07月19日: EuroPython 2010, Birmingham, UK 38 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
 eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
 Registered at Amtsgericht Duesseldorf: HRB 46611
 http://www.egenix.com/company/contact/ 

print repr(sys_version)
returns
'2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3603)'
The format of sys.version now start with a version number
2.6.1 (IronPythons 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
My guess is that with previous version of IronPython this was not the case

Do you want to work on a patch?

Eric,
Yes I like to.
But I am not familiar how to submit a patch.
The file that need to be patched is "C:\Program Files (x86)\IronPython
2.6\Lib\platform.py" for IronPython 2.6.
I thought this file was maintained by Marc-Andre Lemburg
<mal@egenix.com based on the comment in the file platform.py.
It will affect IronPython 2.6 and IronPython 2.6 For .Net 4.0 and
probably IronPython 2.7.
If you give me linsk to read about how to make a patch I would really
like to contribute to IronPython.
Thanks.
Fred.
On Wed, Dec 22, 2010 at 4:02 AM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> Do you want to work on a patch?
>
> ----------
> nosy: +eric.araujo
> stage: -> needs patch
> title: Method _sys_version() module Lib\platform.py does not parse   correctly IronPython 2.x version -> platform._sys_version does not parse correctly IronPython 2.x version
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue8964>
> _______________________________________
>

This is the tracker for CPython, not IronPython, but I assume they synchronize their standard modules with ours, so I think this bug should be fixed here (not in 2.6 though, this old version only gets security fixes).
Guidelines for patches: http://www.python.org/dev/patches/
In short: check out the py3k branch, add a test that fails in Lib/test/test_platform.py (in the test_sys_version method), then patch the code to make the test pass.

I've checked sys.version on IronPython 2.6.1, 2.6.2 (same format) and 2.7.4 (slightly different).
The patch includes two new test cases. I've also taken the liberty of adding some newlines in between the items in the dict as I found this code very hard to read otherwise.

The patch looks good, except one nit:
if 'IronPython' in sys_version
is probably not supported in IronPython 2.0, since support for "n-char in m-char" tests were added after Python 2.1.
Now, you can either leave this in and remove the IronPython 2.0 support from platform.py (which is fine, IMO), or change the test to use the .find() method.

Hm, I see. Actually, "in" is already used in this function a little further down:
 elif "PyPy" in sys_version:
So we should change both occurrences then. I'm attaching a v2 with these changes.

It seems the versions of IronPython 1.0 mentioned in test cases do actually support the "in" keyword, so the first version of the patch is probably sufficient.
Example session:
>>> sys.version
IronPython 1.0.60816 on .NET 2.0.50727.3643
>>> "IronPython" in sys.version
True
>>> sys.version.startswith("IronPython")
True

On 19.10.2013 07:06, Martin Matusiak wrote:
> 
> Martin Matusiak added the comment:
> 
> It seems the versions of IronPython 1.0 mentioned in test cases do actually support the "in" keyword, so the first version of the patch is probably sufficient.
> 
> Example session:
> 
>>>> sys.version
> IronPython 1.0.60816 on .NET 2.0.50727.3643
>>>> "IronPython" in sys.version
> True
>>>> sys.version.startswith("IronPython")
> True
In that case, I'm +1 on using both to clean up the code.

Attaching a v3 which uses "in" and "startswith".
Just for good measure I ran this module on IronPython 1.0 and it fails on import:
- bytes literal: b'(__libc_init)'
- "if" as infix operator: line 177
- "unexpected token open": use of "with" context manager on line 334
- "as" keyword: except OSError as why: line 430
- ImportError: No module named os. os and subprocess are missing altogether in IronPython 1.0.
That's as far as I looked - there may be other issues still. 
So I decided to isolate this one function and see if it works. It fails because re.ASCII does not exist. If I remove that then the function runs and parses its own sys.version correctly.
But it may be a bit of a stretch at this point to stay compatible that far back.

On 19.10.2013 12:11, Martin Matusiak wrote:
> 
> Attaching a v3 which uses "in" and "startswith".
> 
> 
> Just for good measure I ran this module on IronPython 1.0 and it fails on import:
> 
> - bytes literal: b'(__libc_init)'
> - "if" as infix operator: line 177
> - "unexpected token open": use of "with" context manager on line 334
> - "as" keyword: except OSError as why: line 430
> - ImportError: No module named os. os and subprocess are missing altogether in IronPython 1.0.
> 
> That's as far as I looked - there may be other issues still. 
> 
> So I decided to isolate this one function and see if it works. It fails because re.ASCII does not exist. If I remove that then the function runs and parses its own sys.version correctly.
> 
> But it may be a bit of a stretch at this point to stay compatible that far back.
Well, there's a catch here: the trunk version of platform.py is for
Python 3. This does not need to stay backwards compatible to Python 2
(but keeping it close to the Python 2 version helps make merges easier).
Then there's the Python 2.7 version, which receives patches like yours.
This has to stay compatible for Python versions relying on it, which
are in particular older IronPython and Jython versions that don't
ship with their own stdlib.
I think it's ok to use Python 2.4 as the latest version supported
by the Python 2.7 platform.py. The module is used for creating
Python packages and 2.4 is still used by some Zope/Plone installations.
If IronPython 1.0 does not support Python 2.4, we don't need to
support it in the 2.7 version of platform.py.

Double checked that the test passes against both default and 2.7 branches.
Is there anything else that needs to happen here or are you satisfied, Marc-Andre?

On 19.10.2013 13:37, Martin Matusiak wrote:
> 
> Martin Matusiak added the comment:
> 
> Double checked that the test passes against both default and 2.7 branches.
> 
> Is there anything else that needs to happen here or are you satisfied, Marc-Andre?
No, that's all :-)
Thanks, Martin.
Unfortunately, I don't have time in the next few days to check this
in. Could one of the other core devs please do ? Thanks.

New changeset 04a163f93ad4 by Ezio Melotti in branch '2.7':
#8964: fix platform._sys_version to handle IronPython 2.6+.
http://hg.python.org/cpython/rev/04a163f93ad4
New changeset 10a261824b62 by Ezio Melotti in branch '3.3':
#8964: fix platform._sys_version to handle IronPython 2.6+.
http://hg.python.org/cpython/rev/10a261824b62
New changeset 1f7d8a42904c by Ezio Melotti in branch 'default':
#8964: merge with 3.3.
http://hg.python.org/cpython/rev/1f7d8a42904c 

Fixed, thanks for the patch!

On 21.10.2013 02:07, Ezio Melotti wrote:
> 
> Ezio Melotti added the comment:
> 
> Fixed, thanks for the patch!
Thanks, Ezio, for the check-in.