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.RegexFlag is not included in __all__, makes type inference less useful #75550
Comments
It exists and its flags are exported, but not the direct classes itself. This seems inconsistent to me and fixing it would make things like using static typing on it just a little bit easier. |
I think RegexFlag is an implementation detail, but it is true that it isn't prefixed with a _ so putting it in __all__ is not obviously wrong. However, if we do that we should also document it (currently it is mentioned only in a versionchanged line, which isn't technically documenting it). I find it curious that static typing is affected by __all___, but I don't really know anything about typing. |
I suppose it may be an implementation detail, though I wouldn't be amazed that had enum existed when re was written it'd have been used instead of constant integers at the time. Though I do suppose exposing it fully would add two ways to get the flags which I can see how it would be considered bad. It's still useful for type checking though, and while I did make a PR to add it to typeshed, that still leaves it in an iffy state and I probably would not be the last person to be confused by it initially. |
Well, I consider that they really should be named constants and not an enum, which is why I consider it an implementation detail :) |
@ethan.furman, since you had originally added RegexFlag in bpo-28082, do have an opinion on this? Thanks. |
I concur with David. This is an imlementation detail. No need to prefix it with a _ if the module uses __all__for public names. |
I see no reason no prefix As far as adding it to |
I am totally fine with making RegexFlag public (this may be indeed useful for static typing purposes). |
Guido, do you have an opinion on adding There is also some discussion on making these types of int-to-Enum conversions use a used to be: >>> re.I
<RegexFlag.I: 2> is now: >>> re.I
re.IGNORECASE I of course have no idea if that matters to typing one way or the other. |
What it prints is irrelevant to static checking. Currently the typeshed stub for the code already exports RegexFlag, so that the following passes mypy but fails at runtime:
I think it's good to add it to One thing I discovered when developing this example: there doesn't seem to be a flag to represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works fine at runtime). |
Thanks, everyone! |
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: