You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
re: convert re flags to (much friendlier) IntFlag constants #72269
Guido, is this something you wanted to happen? I thought you had objected to propagating the four flavors of enum throughout the standard library, particularly for long standing, stable APIs.
AFAICT, no one has ever requested this for the re module, nor is there any demonstrated need. As a heavy user of regexes, I've have never looked at the flag values (and if I had, it wouldn't have been helpful to hide that these are integer values rather than giving them both a new type and an unattractive appearance: <Flag.ASCII|IGNORECASE: 258>. Also, prior to this change, the re module and its sre components had no external dependencies and did not require any other modules to be loaded in memory to run.
If changes like this do go in, it needs better names (i.e. Flag -> RegexFlag) so that someone using typing doesn't end-up many distinct kinds of integer flags all being called Flag.
The patch was initially from Serhiy as part of bpo-23591. So it's safe to say at least one person requested it, and a core dev at that.
I will happily make it two people: as an occasional user of re having the constants be named makes it much easier for me to use; I daresay that is true for other occasional users. IIRC giving names to numbers was one of the motivating factors in having Enum in the first place.
I do agree that RegexFlag is a better name -- I wasn't real happy with Flag but didn't want to miss the cutoff.
Yeah, I am generally in favor of this. Just yesterday there was a bug report (bpo-28070) where someone claimed that the flags from r'(ix)A' were incorrect. They were 96 and should be 98. (He was right, and it was fixed already.) The way he had to prove that was rather indirect. If the flags had printed like with this proposal it would have been much more straightforward.
I did, immediately after your first post -- it's now RegexFlag. Thank you for the suggestion! Naming things can be hard, especially when trying to beat a deadline.
Activity
ethanfurman commentedon Sep 11, 2016
Split from bpo-23591.
python-dev commentedon Sep 11, 2016
New changeset 223731925d06 by Ethan Furman in branch 'default':
bpo-28082: use IntFlag for re constants
https://hg.python.org/cpython/rev/223731925d06
rhettinger commentedon Sep 11, 2016
Guido, is this something you wanted to happen? I thought you had objected to propagating the four flavors of enum throughout the standard library, particularly for long standing, stable APIs.
AFAICT, no one has ever requested this for the re module, nor is there any demonstrated need. As a heavy user of regexes, I've have never looked at the flag values (and if I had, it wouldn't have been helpful to hide that these are integer values rather than giving them both a new type and an unattractive appearance: <Flag.ASCII|IGNORECASE: 258>. Also, prior to this change, the re module and its sre components had no external dependencies and did not require any other modules to be loaded in memory to run.
If changes like this do go in, it needs better names (i.e. Flag -> RegexFlag) so that someone using typing doesn't end-up many distinct kinds of integer flags all being called Flag.
python-dev commentedon Sep 11, 2016
New changeset 7369ec91d0f7 by Ethan Furman in branch 'default':
bpo-28082: better name for Flag
https://hg.python.org/cpython/rev/7369ec91d0f7
ethanfurman commentedon Sep 11, 2016
The patch was initially from Serhiy as part of bpo-23591. So it's safe to say at least one person requested it, and a core dev at that.
I will happily make it two people: as an occasional user of re having the constants be named makes it much easier for me to use; I daresay that is true for other occasional users. IIRC giving names to numbers was one of the motivating factors in having Enum in the first place.
I do agree that RegexFlag is a better name -- I wasn't real happy with Flag but didn't want to miss the cutoff.
serhiy-storchaka commentedon Sep 11, 2016
re flags was the primary motive of introducing general IntFlags. This would help to handle frequent user error. Original issue is bpo-11957.
ethanfurman commentedon Sep 11, 2016
Note: still need to update docs.
gvanrossum commentedon Sep 11, 2016
Yeah, I am generally in favor of this. Just yesterday there was a bug report (bpo-28070) where someone claimed that the flags from r'(ix)A' were incorrect. They were 96 and should be 98. (He was right, and it was fixed already.) The way he had to prove that was rather indirect. If the flags had printed like with this proposal it would have been much more straightforward.
rhettinger commentedon Sep 11, 2016
Ethan, can you give this class a better name than "Flags"? Perhaps something like "RegexFlags" or somesuch?
ethanfurman commentedon Sep 11, 2016
I did, immediately after your first post -- it's now RegexFlag. Thank you for the suggestion! Naming things can be hard, especially when trying to beat a deadline.
vstinner commentedon Nov 7, 2016
The changeset 223731925d06 caused a performance regression: see issue bpo-28637.
python-dev commentedon Nov 7, 2016
New changeset d903a243c281 by Victor Stinner in branch '3.6':
Issue bpo-28637: Revert issue bpo-28082, don't import enum in re
https://hg.python.org/cpython/rev/d903a243c281
python-dev commentedon Nov 14, 2016
New changeset 5fd69d4a93e0 by Victor Stinner in branch '3.6':
Issue bpo-28637: Reapply changeset 223731925d06
https://hg.python.org/cpython/rev/5fd69d4a93e0
New changeset be66786e95de by Victor Stinner in branch '3.6':
Issue bpo-28082: Add basic unit tests on re enums
https://hg.python.org/cpython/rev/be66786e95de
vstinner commentedon Nov 15, 2016
The change 5fd69d4a93e0 (use IntFlag for re constants) made the "regex_compile" benchmark slower:
Median +- std dev: [71c1970f27b6] 388 ms +- 3 ms -> [3cf248d10bed] 470 ms +- 4 ms: 1.21x slower
python-dev commentedon Nov 21, 2016
New changeset 176fc21f8430 by Ethan Furman in branch '3.6':
closes bpo-28082: doc update and NEWS entry
https://hg.python.org/cpython/rev/176fc21f8430
python-dev commentedon Nov 21, 2016
New changeset 493359386360 by Ethan Furman in branch '3.6':
bpo-28082: actually include NEWS entry
https://hg.python.org/cpython/rev/493359386360