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

typing.Never and typing.assert_never #90633

Closed
JelleZijlstra opened this issue Jan 22, 2022 · 12 comments
Closed

typing.Never and typing.assert_never #90633

JelleZijlstra opened this issue Jan 22, 2022 · 12 comments
Assignees
Labels
3.11 stdlib type-feature

Comments

@JelleZijlstra
Copy link
Member

@JelleZijlstra JelleZijlstra commented Jan 22, 2022

BPO 46475
Nosy @gvanrossum, @davidfstr, @JelleZijlstra, @sobolevn, @Fidget-Spinner, @AlexWaygood
PRs
  • #30842
  • 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 = 'https://github.com/JelleZijlstra'
    closed_at = <Date 2022-02-08.19:07:21.141>
    created_at = <Date 2022-01-22.22:48:21.675>
    labels = ['type-feature', 'library', '3.11']
    title = 'typing.Never and typing.assert_never'
    updated_at = <Date 2022-02-08.19:07:21.140>
    user = 'https://github.com/JelleZijlstra'

    bugs.python.org fields:

    activity = <Date 2022-02-08.19:07:21.140>
    actor = 'JelleZijlstra'
    assignee = 'JelleZijlstra'
    closed = True
    closed_date = <Date 2022-02-08.19:07:21.141>
    closer = 'JelleZijlstra'
    components = ['Library (Lib)']
    creation = <Date 2022-01-22.22:48:21.675>
    creator = 'JelleZijlstra'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 46475
    keywords = ['patch']
    message_count = 5.0
    messages = ['411297', '411301', '411309', '411347', '412860']
    nosy_count = 6.0
    nosy_names = ['gvanrossum', 'David Foster', 'JelleZijlstra', 'sobolevn', 'kj', 'AlexWaygood']
    pr_nums = ['30842']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue46475'
    versions = ['Python 3.11']

    @JelleZijlstra
    Copy link
    Member Author

    @JelleZijlstra JelleZijlstra commented Jan 22, 2022

    At the moment, https://docs.python.org/3.10/library/typing.html#typing.NoReturn simply says:

    Special type indicating that a function never returns.
    

    In practice, type checkers accept NoReturn as a bottom type in other positions too. We should document this behavior.

    @sobolevn
    Copy link
    Member

    @sobolevn sobolevn commented Jan 22, 2022

    I agree.

    Plus, I cannot refrain from saying that it is generally quite hard to teach what "NoReturn" is.

    I start by explaining what bottom type and void is and then just say that in Python it is called NoReturn. I remember that there was a discussion about Never alias for it.

    Jelle, will you please push it? :)

    @AlexWaygood
    Copy link
    Member

    @AlexWaygood AlexWaygood commented Jan 22, 2022

    I also agree that documenting this is a great idea. It's already been adopted by large swathes of the typing community for use in this context. The value of having NoReturn act as a "bottom type" is evident. Time to make it official, in my opinion.

    @JelleZijlstra
    Copy link
    Member Author

    @JelleZijlstra JelleZijlstra commented Jan 23, 2022

    Based on feedback here and on typing-sig I'm now leaning towards adding typing.Never along with typing.assert_never. I'll submit a single patch for these as the documentation will be closely linked.

    @JelleZijlstra JelleZijlstra changed the title Document use of NoReturn as a bottom type typing.Never and typing.assert_never Jan 23, 2022
    @JelleZijlstra JelleZijlstra added type-feature and removed 3.9 3.10 labels Jan 23, 2022
    @JelleZijlstra JelleZijlstra changed the title Document use of NoReturn as a bottom type typing.Never and typing.assert_never Jan 23, 2022
    @JelleZijlstra JelleZijlstra added the type-feature label Jan 23, 2022
    @gvanrossum
    Copy link
    Member

    @gvanrossum gvanrossum commented Feb 8, 2022

    New changeset 243436f by Jelle Zijlstra in branch 'main':
    bpo-46475: Add typing.Never and typing.assert_never (GH-30842)
    243436f

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @ptmcg
    Copy link

    @ptmcg ptmcg commented Apr 19, 2022

    What is the purpose of the required argument to assert_never()? Regardless of what I pass to this function, the raised exception is "AssertionError: Expected code to be unreachable"

    @JelleZijlstra
    Copy link
    Member Author

    @JelleZijlstra JelleZijlstra commented Apr 19, 2022

    @ptmcg it always throws at runtime; the point is that static typecheckers will verify that the code really is unreachable. See https://docs.python.org/3.11/library/typing.html#typing.assert_never and https://typing.readthedocs.io/en/latest/source/unreachable.html

    @gvanrossum
    Copy link
    Member

    @gvanrossum gvanrossum commented Apr 19, 2022

    IIUC the question is why does it have an argument and what effect does it have? (It seems to have none, then why is it required?)

    @ptmcg
    Copy link

    @ptmcg ptmcg commented Apr 19, 2022

    Thank you @gvanrossum , that is what I was asking.

    @JelleZijlstra
    Copy link
    Member Author

    @JelleZijlstra JelleZijlstra commented Apr 19, 2022

    I see. Usually you'd use this function in a place where some variable gets narrowed down to Never. Making it an explicit argument makes it possible to implement the function without any special casing in type checkers, because they already know how to treat Never in an argument position.

    We could add a similar function with no arguments that asserts a block is unreachable, but unlike assert_never() it would need to be special cased in type checkers.

    We might want to revisit the fact that the error message is always the same. We did that on the basis of security concerns about str() on untrusted input, but I don't find those concerns that convincing, and it's useful to have some representation of the object in the error message.

    @gvanrossum
    Copy link
    Member

    @gvanrossum gvanrossum commented Apr 19, 2022

    Security concerns? That seems excessive. Millions of things in the stdlib print the repr() of the thing that unexpectedly failed some check.

    @JelleZijlstra
    Copy link
    Member Author

    @JelleZijlstra JelleZijlstra commented Apr 20, 2022

    Sending a PR shortly to add the asserted value to assert_never()'s error message, and also to link to https://typing.readthedocs.io/en/latest/source/unreachable.html while I'm at it.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.11 stdlib type-feature
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants