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

Equality of typing.Literal depends on the order of arguments #86511

Closed
Dominik1123 mannequin opened this issue Nov 13, 2020 · 17 comments
Closed

Equality of typing.Literal depends on the order of arguments #86511

Dominik1123 mannequin opened this issue Nov 13, 2020 · 17 comments
Labels
3.8 only security fixes 3.9 only security fixes 3.10 only security fixes type-bug An unexpected behavior, bug, or error

Comments

@Dominik1123
Copy link
Mannequin

Dominik1123 mannequin commented Nov 13, 2020

BPO 42345
Nosy @gvanrossum, @ilevkivskyi, @miss-islington, @uriyyo, @Dominik1123, @Fidget-Spinner
PRs
  • bpo-42345: Fix three issues with typing.Literal parameters #23294
  • [3.9] bpo-42345: Fix three issues with typing.Literal parameters (GH-23294) #23335
  • bpo-42345: Fix hash implementation of typing.Literal #23383
  • bpo-42345: Add whatsnew for typing.Literal in 3.10 #23385
  • bpo-42345: Add whatsnew and versionchanged for typing.Literal in 3.9 #23386
  • [3.9] bpo-42345: Fix hash implementation of typing.Literal (GH-23383) #23408
  • [3.9] bpo-42345: Add whatsnew and versionchanged for typing.Literal in 3.9 (GH-23386) #23411
  • 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 2020-11-20.17:11:24.442>
    created_at = <Date 2020-11-13.14:11:55.639>
    labels = ['type-bug', '3.8', '3.9', '3.10']
    title = 'Equality of typing.Literal depends on the order of arguments'
    updated_at = <Date 2021-10-13.10:26:49.678>
    user = 'https://github.com/Dominik1123'

    bugs.python.org fields:

    activity = <Date 2021-10-13.10:26:49.678>
    actor = 'kj'
    assignee = 'none'
    closed = True
    closed_date = <Date 2020-11-20.17:11:24.442>
    closer = 'gvanrossum'
    components = []
    creation = <Date 2020-11-13.14:11:55.639>
    creator = 'Dominik V.'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 42345
    keywords = ['patch']
    message_count = 17.0
    messages = ['380888', '380904', '381018', '381050', '381204', '381247', '381249', '381380', '381388', '381439', '381441', '381445', '381446', '381448', '381469', '403752', '403818']
    nosy_count = 7.0
    nosy_names = ['gvanrossum', 'alick', 'levkivskyi', 'miss-islington', 'uriyyo', 'Dominik V.', 'kj']
    pr_nums = ['23294', '23335', '23383', '23385', '23386', '23408', '23411']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue42345'
    versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

    @Dominik1123
    Copy link
    Mannequin Author

    Dominik1123 mannequin commented Nov 13, 2020

    PEP-586 specifies that

    Literal[v1, v2, v3]
    

    is equivalent to

    Union[Literal[v1], Literal[v2], Literal[v3]]
    

    Since the equality of Unions doesn't take into account the order of arguments, Literals parametrized with multiple arguments should not be order dependent either. However they seem to:

        >>> Literal[1, 2] == Literal[2, 1]
        False

    Compare with the equivalent form:

        >>> Union[Literal[1], Literal[2]] == Union[Literal[2], Literal[1]]
        True

    In addition to that, the PEP specifies that nested Literals should be equivalent to the flattened version (https://www.python.org/dev/peps/pep-0586/#legal-parameters-for-literal-at-type-check-time). This section is titled "Legal parameters for Literal at type check time" but since the PEP doesn't specify runtime behavior differently, I think it makes sense to assume it is the same. It seems to be different though:

        >>> Literal[Literal[1, 2], 3]
        typing.Literal[typing.Literal[1, 2], 3]
        >>> Literal[Literal[1, 2], 3] == Literal[1, 2, 3]
        False

    Also the flattening follows from the above definition Literal[v1, v2, v3] == Union[Literal[v1], Literal[v2], Literal[v3]] and the fact that Unions are flattened.

    @Dominik1123 Dominik1123 mannequin added 3.9 only security fixes type-bug An unexpected behavior, bug, or error labels Nov 13, 2020
    @gvanrossum
    Copy link
    Member

    Probably the implementation focused on static typing, not runtime checking.

    Can you come up with a PR for a fix?

    @gvanrossum gvanrossum added 3.8 only security fixes 3.10 only security fixes labels Nov 13, 2020
    @Fidget-Spinner
    Copy link
    Member

    @guido and @ivan,

    Should Literals de-duplicate values in its __args__ similar to Union? PEP-586 states that:

    Literal[v1, v2, v3] is equivalent to Union[Literal[v1], Literal[v2], Literal[v3]]

    Naturally, a Union de-duplicates values, so I was wondering if Literal should follow.

    @gvanrossum
    Copy link
    Member

    Yeah, I think it makes sense to de-dupe args for Literal.

    @miss-islington
    Copy link
    Contributor

    New changeset f03d318 by Yurii Karabas in branch 'master':
    bpo-42345: Fix three issues with typing.Literal parameters (GH-23294)
    f03d318

    @miss-islington
    Copy link
    Contributor

    New changeset ac472b3 by Yurii Karabas in branch '3.9':
    [3.9] bpo-42345: Fix three issues with typing.Literal parameters (GH-23294) (GH-23335)
    ac472b3

    @gvanrossum
    Copy link
    Member

    I recommend adding a whatsnew entry too. You can just add it to this issue. Interestingly you’ll probably need two separate ones, for 3.9 and 3.10. That would become two separate PRs for master, the 3.9 one to be backported.

    @gvanrossum
    Copy link
    Member

    We need to fix this to make __hash__ match __eq__.

    @gvanrossum gvanrossum reopened this Nov 18, 2020
    @gvanrossum gvanrossum reopened this Nov 18, 2020
    @gvanrossum
    Copy link
    Member

    New changeset 4687338 by kj in branch 'master':
    bpo-42345: Add whatsnew for typing.Literal in 3.10 (GH-23385)
    4687338

    @miss-islington
    Copy link
    Contributor

    New changeset 1b54077 by Yurii Karabas in branch 'master':
    bpo-42345: Fix hash implementation of typing.Literal (GH-23383)
    1b54077

    @miss-islington
    Copy link
    Contributor

    New changeset 2acd9d0 by Miss Islington (bot) in branch '3.9':
    bpo-42345: Fix hash implementation of typing.Literal (GH-23383)
    2acd9d0

    @miss-islington
    Copy link
    Contributor

    New changeset e1dc0db by kj in branch 'master':
    bpo-42345: Add whatsnew and versionchanged for typing.Literal in 3.9 (GH-23386)
    e1dc0db

    @gvanrossum
    Copy link
    Member

    Thanks everyone! Can I close this now?

    @miss-islington
    Copy link
    Contributor

    New changeset 1051ca4 by Miss Islington (bot) in branch '3.9':
    bpo-42345: Add whatsnew and versionchanged for typing.Literal in 3.9 (GH-23386)
    1051ca4

    @uriyyo
    Copy link
    Member

    uriyyo commented Nov 20, 2020

    Looks like everything merged, we can close this issue

    @alick
    Copy link
    Mannequin

    alick mannequin commented Oct 12, 2021

    Mainly to clarify, this is fixed in Python 3.9 and above, but won't be fixed in Python 3.8, right?

    ~$ python3.8
    Python 3.8.11 (default, Jul 24 2021, 13:24:12)
    [Clang 12.0.5 (clang-1205.0.22.11)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    Could not open PYTHONSTARTUP
    FileNotFoundError: [Errno 2] No such file or directory: '/Users/taoz/.pythonstartup'
    >>> from typing import Literal
    >>> Literal[1,2]==Literal[2,1]
    False
    >>>
    

    @Fidget-Spinner
    Copy link
    Member

    @alick yes. To be specific, 3.9.1 and above. 3.9.0 still has the old
    behavior.

    @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.8 only security fixes 3.9 only security fixes 3.10 only security fixes type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants