This looks to be a bug in EPD.
What's going on:
platforms.py attemps, in the function _sys_version
(which is called by python_implementation
, as your stack trace shows) to, in some cases, parse sys.version
with a regex. In your case, it thinks you're running CPython (are you? CPython is the normal Python version, not anything like Jython or IronPython), and that is the case in which the regex gets run. The regex:
_sys_version_parser = re.compile(
r'([w.+]+)s*'
'(#?([^,]+),s*([w ]+),s*([w :]+))s*'
'[([^]]+)]?')
And the code that runs it:
else:
# CPython
match = _sys_version_parser.match(sys_version)
if match is None:
raise ValueError(
'failed to parse CPython sys.version: %s' %
repr(sys_version))
version, buildno, builddate, buildtime, compiler =
match.groups()
name = 'CPython'
builddate = builddate + ' ' + buildtime
The code is fairly simple: it's raising the error because the regex didn't match. Looking at the regex:
r'([w.+]+)s*'
'(#?([^,]+),s*([w ]+),s*([w :]+))s*'
'[([^]]+)]?')
That first part, ([w.+]+)s*
, matches space-separated chunks of [a-zA-Z0-9_.+]
— the function hints that this is the version number. That's probably matching the "2.7.3" correctly.
The second part is much more interesting. The code hints that it's looking for a buildno
, and the regex seems to1 indicate that it's looking for a literal paren ((
). We see this later in your string: (default, Apr 12 2012, 14:30:37)
But this part is in the way: |EPD_free 7.3-2 (32-bit)|
. My guess is that the regex isn't expecting that, and that's what's causing it to choke.
How to fix it:
In the short term, to test this theory, try removing it in Python. Just assign to sys.version
, something like,
# This raises an exception for you:
platform.python_implementation()
# Try this:
sys.version = '2.7.3 (default, Apr 12 2012, 14:30:37) [MSC v.1500 32 bit (Intel)]'
# Hopefully, this no longer raises.
platform.python_implementation()
If that does fix it, you'll probably want to get rid of it long term. I'm assuming this is Enthought Python Distribution Free — you'll probably have to file a bug there, as this is probably something they've done.
1As an aside, there's some weirdness here. The literal should have those backslashes doubled, or be a raw string. (The r from the first literal doesn't, I believe, carry over, however, an unknown escape ends up being slash-whatever, so it still works.)