Repository navigation
Add an explicit re.NOFLAGS flag value to the re module #57594
Description
| BPO | 13385 |
|---|---|
| Nosy | @rhettinger, @terryjreedy, @pitrou, @ericvsmith, @ezio-melotti, @merwok |
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:
assignee = None
closed_at = <Date 2011-11-12.18:13:58.867>
created_at = <Date 2011-11-11.19:39:15.501>
labels = ['expert-regex', 'library']
title = 'Add an explicit re.NOFLAGS flag value to the re module'
updated_at = <Date 2011-11-13.00:05:12.510>
user = 'https://bugs.python.org/elibendersky'bugs.python.org fields:
activity = <Date 2011-11-13.00:05:12.510>
actor = 'rhettinger'
assignee = 'none'
closed = True
closed_date = <Date 2011-11-12.18:13:58.867>
closer = 'eli.bendersky'
components = ['Library (Lib)', 'Regular Expressions']
creation = <Date 2011-11-11.19:39:15.501>
creator = 'eli.bendersky'
dependencies = []
files = []
hgrepos = []
issue_num = 13385
keywords = []
message_count = 9.0
messages = ['147443', '147444', '147448', '147451', '147458', '147460', '147505', '147515', '147536']
nosy_count = 7.0
nosy_names = ['rhettinger', 'terry.reedy', 'pitrou', 'eric.smith', 'ezio.melotti', 'eric.araujo', 'eli.bendersky']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue13385'
versions = ['Python 3.3']
Activity
elibendersky commentedon Nov 11, 2011
The flags 're' accept are numeric underneath, and the current value of "no flags" is just 0, which is also specified in the documentation as the default value. However, using raw numeric values is not a good programming practice.
The suggestion is to add a simple re.NOFLAGS constant to the 're' module with the value of 0, and use it in the documentation instead of plain 0. It's a simple change that won't break anything and may provide better readability for some code, as well as remove the need for plain integer references in the documentation.
See also issues bpo-11957 and bpo-12875.
Adding to nosy people taking part in discussion of the aforementioned issue. If you're not interested, please remove yourself - I apologize in advance.
ericvsmith commentedon Nov 11, 2011
Since the flags are OR'd together, I don't see what other value the "no flags" parameter could have, other than zero. That said, I don't feel strongly about it, and if it helps readability I'm not opposed.
pitrou commentedon Nov 11, 2011
As Eric, I don't really think it's useful, and it might actually be confusing (people will start wondering if there's a difference between 0 and NOFLAGS).
ezio-melotti commentedon Nov 11, 2011
I think a proper solution would be fixing bpo-11957. Adding a NOFLAGS alias for 0 would help fixing bpo-12875, but I don't think it will be useful/use otherwise.
elibendersky commentedon Nov 12, 2011
Antoine, what's the outcome of people wondering about the difference? I don't see what's bad about it, it's not as if people are writing (or supposed to write) code that does arithmetic on these flag values. Their only usage is to:
The "OR" (which makes no mathematical sense in this case) is bad enough, but why not provide an easy fix for (1), making it explicit instead of implicit. I think we sometimes forget that not everyone who picks up Python is an old C dog, familiar with these tricks. To newbies for whom Python is the first language, these flags aren't very intuitive to use, I imagine.
ezio-melotti commentedon Nov 12, 2011
If you want to provide no flags, I think it's easier to provide no flags, rather than having to learn some NOFLAGS constant value that can be used to make the fact that you are passing no flags more explicit than it already is.
I might agree that ORing flags might not be the best API ever, but that a separate problem. So in my opinion there's nothing to fix about 1.
merwok commentedon Nov 12, 2011
I had too the need to find out the value to pass when there are no flags, so a mention of 0 in the doc would have been enough for me. -0 on a new constant.
elibendersky commentedon Nov 12, 2011
I think we have enough < 0 to reject the issue. Closing.
rhettinger commentedon Nov 13, 2011
Thank you for closing this. I think it would only add clutter to a module that is already puts readers into information overload.
Stevoisiak commentedon Feb 10, 2023
This has been implemented in Python 3.11 via #30279