Navigation Menu

Skip to content
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

Closed
PJB3005 mannequin opened this issue Sep 6, 2017 · 12 comments
Closed

re.RegexFlag is not included in __all__, makes type inference less useful #75550

PJB3005 mannequin opened this issue Sep 6, 2017 · 12 comments
Labels
3.11 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@PJB3005
Copy link
Mannequin

PJB3005 mannequin commented Sep 6, 2017

BPO 31369
Nosy @gvanrossum, @ezio-melotti, @bitdancer, @ethanfurman, @serhiy-storchaka, @ilevkivskyi, @csabella, @PJB3005, @akulakov
PRs
  • bpo-31369: include RegexFlag in re.__all__  #30279
  • 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 2022-02-05.03:55:29.850>
    created_at = <Date 2017-09-06.20:40:02.513>
    labels = ['type-bug', 'library', '3.11']
    title = 're.RegexFlag is not included in __all__, makes type inference less useful'
    updated_at = <Date 2022-02-05.03:55:29.842>
    user = 'https://github.com/PJB3005'

    bugs.python.org fields:

    activity = <Date 2022-02-05.03:55:29.842>
    actor = 'ethan.furman'
    assignee = 'none'
    closed = True
    closed_date = <Date 2022-02-05.03:55:29.850>
    closer = 'ethan.furman'
    components = ['Library (Lib)']
    creation = <Date 2017-09-06.20:40:02.513>
    creator = 'PJB3005'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 31369
    keywords = ['patch']
    message_count = 12.0
    messages = ['301516', '301529', '301532', '301536', '338567', '338583', '338815', '339545', '376815', '376841', '412557', '412558']
    nosy_count = 11.0
    nosy_names = ['gvanrossum', 'ezio.melotti', 'mrabarnett', 'r.david.murray', 'docs@python', 'ethan.furman', 'serhiy.storchaka', 'levkivskyi', 'cheryl.sabella', 'PJB3005', 'andrei.avk']
    pr_nums = ['30279']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue31369'
    versions = ['Python 3.11']

    @PJB3005
    Copy link
    Mannequin Author

    PJB3005 mannequin commented Sep 6, 2017

    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.

    @PJB3005 PJB3005 mannequin added the topic-regex label Sep 6, 2017
    @bitdancer
    Copy link
    Member

    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.

    @bitdancer bitdancer added docs Documentation in the Doc dir 3.7 (EOL) end of life labels Sep 6, 2017
    @PJB3005
    Copy link
    Mannequin Author

    PJB3005 mannequin commented Sep 6, 2017

    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.

    @bitdancer
    Copy link
    Member

    Well, I consider that they really should be named constants and not an enum, which is why I consider it an implementation detail :)

    @csabella
    Copy link
    Contributor

    @ethan.furman, since you had originally added RegexFlag in bpo-28082, do have an opinion on this? Thanks.

    @csabella csabella added the 3.8 only security fixes label Mar 21, 2019
    @serhiy-storchaka
    Copy link
    Member

    I concur with David. This is an imlementation detail. No need to prefix it with a _ if the module uses __all__for public names.

    @ethanfurman
    Copy link
    Member

    I see no reason no prefix RegexFlag with an _.

    As far as adding it to __all__ -- I didn't originally because I was trying to mirror the original implementation, but I am not against it. I would defer that decision to those that work on typing.

    @ethanfurman ethanfurman removed the docs Documentation in the Doc dir label Mar 25, 2019
    @ethanfurman ethanfurman changed the title re.RegexFlag is not included in __all__ re.RegexFlag is not included in __all__, makes type inference less useful Mar 25, 2019
    @ilevkivskyi
    Copy link
    Member

    I am totally fine with making RegexFlag public (this may be indeed useful for static typing purposes).

    @ethanfurman
    Copy link
    Member

    Guido, do you have an opinion on adding RegexFlag to the re module's __all__ and documenting it?

    There is also some discussion on making these types of int-to-Enum conversions use a module.name repr instead of class.name:

    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.

    @gvanrossum
    Copy link
    Member

    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:

    from re import *
    
    def foo(flag: RegexFlag):
        return match("[a-z]+", "ABC", flag)
    
    print(foo(IGNORECASE))
    print(foo(VERBOSE))
    

    I think it's good to add it to __all__ so this code will not put the type checker to shame, and it would be good to document it.

    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).

    @ethanfurman
    Copy link
    Member

    New changeset fea7290 by andrei kulakov in branch 'main':
    bpo-31369: include RegexFlag in re.__all__ (GH-30279)
    fea7290

    @ethanfurman
    Copy link
    Member

    Thanks, everyone!

    @ethanfurman ethanfurman added 3.11 only security fixes stdlib Python modules in the Lib dir and removed 3.7 (EOL) end of life 3.8 only security fixes topic-regex labels Feb 5, 2022
    @ethanfurman ethanfurman added the type-bug An unexpected behavior, bug, or error label Feb 5, 2022
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.11 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    6 participants