Bug 1319880
Summary: | python34-3.4.3-4 ships /usr/bin/python3 | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Troels Arvin <troels> |
Component: | python34 | Assignee: | Petr Viktorin (pviktori) <pviktori> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | cstratak, fschwarz, jberan, kevin, mstuchli, orion, pviktori |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-01-10 16:15:03 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Troels Arvin
2016-03-21 18:01:54 UTC
Are you sure it's caused by the version update? AFAIK Python has had this limit since 2.5.
$ python
Python 2.7.10 (default, Sep 8 2015, 17:20:17)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile('(a)'*100)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.7/re.py", line 194, in compile
return _compile(pattern, flags)
File "/usr/lib64/python2.7/re.py", line 249, in _compile
p = sre_compile.compile(pattern, flags)
File "/usr/lib64/python2.7/sre_compile.py", line 583, in compile
"sorry, but this version only supports 100 named groups"
AssertionError: sorry, but this version only supports 100 named groups
The examples you give are not enough to reproduce. They don't have any named groups (i.e. sub-regex enclosed in parentheses).
If you don't need named groups, a workaround would be to replace ( by \( and ) by \) in "exclusions".
I know: I hit the limit with Python 2.7; that's why I installed python34 in the first place. When I downgrade to python34-3.4.3-2, my script works again. Python 3 is not supposed to remove this limitation. You might be hitting an edge case here but I believe that adding one more named group will make the script stop working even with the old release. Alternatively, you can install use the "regex" library (python3-regex) instead of "re". It's designed to be backwards-compatible, but uses a reworked engine that removes this limitation. (fyi python-3.5 removes this limitation) Sorry: My mistake. Some paths-stuff meant that I was actually using a locally (non-RPM) compiled Python 3.5 when my script was working. The difference is probably that the python34-3.4.3-3 or python34-3.4.3-4 added /bin/python3 which was not present in python34-3.4.3-2. Thus, after the update, my locally compiled Python 3.5 was no longer executed when "python3" was executed. Actually, I think that's perhaps a problem - I'm not sure we were meant to ship /usr/bin/python3 with these packages. However, the conditional is: # pybasever without the dot: %global pyshortver 34 # is this the EPEL 7 main Python 3? %if "%python3_pkgversion" == "%pyshortver" %global main_python3 1 I'm surprised this didn't take effect on the original build. Perhaps the macros weren't in the buildroot at that point? What is the expected behavior here? I guess the ship sailed by now as python34 in EPEL7 contains /usr/bin/python3 for almost a year and by now for sure there are other users depending on this. My 2ยข: I think python34 should indeed provide /usr/bin/python3 similar to Python 2.7 providing /usr/bin/python2 so the changes looks good and this bug should be closed. (If you have a self-compiled Python 3 ensure that it does not install anything in /usr/bin/.) |