GeezerVison is showing github.com — 3.11.0b1 regression: re.template removed without a deprecation period · Issue #92728 · python/cpython
3.11.0b1 regression: re.template removed without a deprecation period #92728Description
Bug report
In Python 3.10, the re.template function exists and is not deprecated:
>>> import re
>>> re.template('', re.I)
re.compile('', re.TEMPLATE|re.IGNORECASE)In Python 3.11.0b1 this function is gone:
>>> import re
>>> re.template('', re.I)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 're' has no attribute 'template'This was removed in b09184bf05 without a depreciation period.
Despite being undocumented, projects actually use this function, see e.g. rpm-software-management/dnf#1827
Please restore this function and deprecate it in 3.11 and 3.12 if you want to remove it in 3.13. (That is how I understand PEP 387, section Making Incompatible Changes.)
Your environment
- CPython versions tested on: 3.11.0b1
- Operating system and architecture: All
Activityhroncok commented on May 12, 2022 ContributorAuthor More actions I intend to send a PR later today.
However, I am not sure if I can revert the removal + deprecate after the feature freeze, or if I must only revert the removal in 3.11 and deprecate it in 3.12+. Will start with a PR to main anyway.
EDIT: I won't send a PR before there is a consensus. vstinner commented on May 12, 2022 vstinner commented on May 12, 2022 The discussion started in this larger issue about re "reorganization": #91308 vstinner commented on May 12, 2022 I don't understand the purpose of the re.template() function and the re.TEMPLATE flag. It doesn't seem to disable backtracking:
>>> re.compile(r"((a)b\2)", re.IGNORECASE).match("aba").groups()
('aba', 'a')
>>> re.template(r"((a)b\2)", re.IGNORECASE).match("aba").groups()
('aba', 'a')
The only thing which seems to be changed is that repetition is not supported by TEMPLATE:
>>> re.template(r"a+")
re.error: internal: unsupported template operator MAX_REPEAT
>>> re.template(r"a*")
re.error: internal: unsupported template operator MAX_REPEAT
vstinner commented on May 12, 2022 Code search for "TEMPLATE" in re/sre source code files of Python 3.10:
Lib/re.py: TEMPLATE = T = sre_compile.SRE_FLAG_TEMPLATE # disable backtracking
Lib/sre_compile.py: if flags & SRE_FLAG_TEMPLATE:
Lib/sre_constants.py:SRE_FLAG_TEMPLATE = 1 # template mode (disable backtracking)
Lib/sre_constants.py: f.write("#define SRE_FLAG_TEMPLATE %d\n" % SRE_FLAG_TEMPLATE)
Lib/sre_parse.py: "t": SRE_FLAG_TEMPLATE,
Lib/sre_parse.py:GLOBAL_FLAGS = SRE_FLAG_DEBUG | SRE_FLAG_TEMPLATE
Modules/sre_constants.h:#define SRE_FLAG_TEMPLATE 1
vstinner commented on May 12, 2022 hroncok commented on May 12, 2022 ContributorAuthor More actions To be honest, I don't understand the purpose of the re.template() function either and I think that deprecating and removing it is a good thing. vstinner commented on May 12, 2022 If we decide to not revert the change, I suggest to document the removal in What's New in Python 3.11 and explain how to port impacted applications. For example, replace re.template() with re.compile(). hroncok commented on May 12, 2022 ContributorAuthor More actions
If we decide to not revert the change, I suggest to document the removal in What's New in Python 3.11 and explain how to port impacted applications. For example, replace re.template() with re.compile().
I suppose we should do that even if we "just" deprecate it. hugovk commented on May 12, 2022 DanielNoord commented on May 13, 2022 I have no opinion on this particular removal/deprecation, but just quickly want to point to PEP8 (https://peps.python.org/pep-0008/#public-and-internal-interfaces) and it's directive that:
To better support introspection, modules should explicitly declare the names in their public API using the __all__ attribute. Setting __all__ to an empty list indicates that the module has no public API.. Previously, template was in __all__ which is also pre-faced with a # public symbols comment.
Perhaps there are reasons why this does not hold true for CPython, but it would be good if that could be documented somewhere. As a package maintainer I have recently been struggling to correctly determine what is and isn't public in a codebase that does not currently document this. So guidelines such as the one in the PEP and general agreement on those guidelines would be helpful for me and the wider ecosystem I think. Reacted by Petr Viktorin and Dominic Davis-Foster hroncok commented on May 24, 2022 ContributorAuthor More actions
But if you think that it is worth, I am not opposing to reverting #32300 and adding a deprecation warning instead.
Yes, I believe that would be in the spirit of the policy. I will try to draft a PR shortly and then I will leave it for the others to decide if it's worth it. serhiy-storchaka commented on May 24, 2022 How long the deprecation period should be? Would the only 3.11 be enough? hroncok commented on May 24, 2022 ContributorAuthor More actions The policy speaks of 2 releases. hroncok commented on May 24, 2022 ContributorAuthor More actions encukou commented on May 24, 2022 @rhettinger:
Undocumented functions do not require a deprecation period.
I disagree.
Is this documented somewhere, or is it tribal knowledge (which should be documented, now that we have PEP-387 written)? Reacted by Dominic Davis-Foster serhiy-storchaka commented on May 25, 2022 Thank you @hugovk for your investigation and PR. hugovk commented on May 25, 2022 Reacted by Miro Hrončok and Alex Waygood
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|