New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove deprecated re features #71217
Comments
Proposed patch removes following deprecated re features:
|
New changeset 09d1af3fe332 by Serhiy Storchaka in branch 'default': |
Thanks Jim for the review. |
New changeset 8ed3880e94e5 by Serhiy Storchaka in branch 'default': |
New changeset a2482e805dff by Martin Panter in branch '3.5': New changeset be193f8dbe4c by Martin Panter in branch 'default': New changeset c5411cfa0bd3 by Martin Panter in branch '2.7': |
FWIW, this breaks Mailman 3.1 (and probably 2.1) |
Specifically, point #2; undefined combinations of \ + ASCII becoming an error. |
On Nov 22, 2016, at 04:13 PM, Serhiy Storchaka wrote:
No, I think this is a valid bug/regression. The Mailman code is basically trying to do this: p = re.compile('%\d*d')
p.sub(r'\s*\d+\s*', some_string) And so we get the error: sre_constants.error: bad escape \s at position 0 But this directly contradicts the documentation for re.sub(): "... if it is a string, any backslash escapes in it are processed. That is, \n Clearly \s is not being left alone, so this is a real regression. |
This part of the documentation was just overlooked. bpo-28450 is opened for this. |
If you insist I could revert converting warnings to errors (only in replacement string or all?) in 3.6. But I think they should left errors in 3.7. The earlier we make undefined escapes the errors, the earlier we can define new special escape sequences without confusing users. It is bad if the escape sequence is valid in two Python versions but has different meaning. |
There is still the argument that we shouldn't break 2.7 compatibility unnecessarily until 2.7 is out of maintenance. That is: warnings are good, removals are bad. (I haven't read through this issue, so I may be off base.) |
Here is a patch that partially reverts changes of bpo-27030. It allows using unknown escapes in re.sub() replacement template, but they are deprecated and will be errors in 3.7. If this is good to you Barry, and Ned allows, it can be committed in 3.6 only. But this could delay adding support of new escapes (like \xXX, \uXXXX, etc) in replacement templates. |
It is unfortunate that the deprecation note did not explicitly mention replacement templates as well as regexp patterns. While there are good arguments to be made for either case, I think it makes more sense to treat the replacement template as following the rules for strings rather than for regexps which would argue for making the proposed change to cause only a deprecation warning in templates for 3.6 - although I'm not happy about making such a change at the last minute. Serhiy, please push to 3.6 for rc1. There should also be a note in the What's New for 3.6 document. |
New changeset 1b162d6e3d01 by Serhiy Storchaka in branch '3.6': New changeset 5904d2ced3d8 by Serhiy Storchaka in branch 'default': |
Thanks, Serhiy, for reverting the error handling for 3.6.0 (in 3.6.0rc1). I'm going to mark this as closed. bpo-28450 is still open at the moment regarding the documentation and possible 3.7 changes. |
Misc/NEWS
so that it is managed by towncrier #552Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: