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
re: convert re flags to (much friendlier) IntFlag constants #72269
Comments
Split from bpo-23591. |
New changeset 223731925d06 by Ethan Furman in branch 'default': |
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. |
New changeset 7369ec91d0f7 by Ethan Furman in branch 'default': |
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. |
re flags was the primary motive of introducing general IntFlags. This would help to handle frequent user error. Original issue is bpo-11957. |
Note: still need to update docs. |
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. |
Ethan, can you give this class a better name than "Flags"? Perhaps something like "RegexFlags" or somesuch? |
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. |
The changeset 223731925d06 caused a performance regression: see issue bpo-28637. |
New changeset d903a243c281 by Victor Stinner in branch '3.6': |
New changeset 5fd69d4a93e0 by Victor Stinner in branch '3.6': New changeset be66786e95de by Victor Stinner in branch '3.6': |
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 |
New changeset 176fc21f8430 by Ethan Furman in branch '3.6': |
New changeset 493359386360 by Ethan Furman in branch '3.6': |
Note: 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: