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

Implement __class_getitem__ for Future, Task, Queue #83159

Closed
asvetlov opened this issue Dec 5, 2019 · 11 comments
Closed

Implement __class_getitem__ for Future, Task, Queue #83159

asvetlov opened this issue Dec 5, 2019 · 11 comments
Labels
3.9 only security fixes easy topic-asyncio

Comments

@asvetlov
Copy link
Contributor

asvetlov commented Dec 5, 2019

BPO 38978
Nosy @gvanrossum, @asvetlov, @ambv, @1st1, @ilevkivskyi, @miss-islington, @isidentical
PRs
  • bpo-38978: Implement __class_getitem__ for asyncio objects #17491
  • 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 2019-12-07.11:05:46.373>
    created_at = <Date 2019-12-05.12:53:23.654>
    labels = ['easy', '3.9', 'expert-asyncio']
    title = 'Implement __class_getitem__ for Future, Task, Queue'
    updated_at = <Date 2019-12-07.15:49:04.739>
    user = 'https://github.com/asvetlov'

    bugs.python.org fields:

    activity = <Date 2019-12-07.15:49:04.739>
    actor = 'BTaskaya'
    assignee = 'none'
    closed = True
    closed_date = <Date 2019-12-07.11:05:46.373>
    closer = 'asvetlov'
    components = ['asyncio']
    creation = <Date 2019-12-05.12:53:23.654>
    creator = 'asvetlov'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 38978
    keywords = ['patch', 'easy', 'easy (C)']
    message_count = 11.0
    messages = ['357848', '357854', '357857', '357864', '357875', '357876', '357885', '357965', '357966', '357967', '357977']
    nosy_count = 7.0
    nosy_names = ['gvanrossum', 'asvetlov', 'lukasz.langa', 'yselivanov', 'levkivskyi', 'miss-islington', 'BTaskaya']
    pr_nums = ['17491']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue38978'
    versions = ['Python 3.9']

    @asvetlov
    Copy link
    Contributor Author

    asvetlov commented Dec 5, 2019

    Typeshed declares asyncio.Future, asyncio.Task and asyncio.Queue as generic types, which is 100% correct.

    The problem is that these classes don't support generic instantiation in runtime, e.g. Future[str] raises TypeError.

    The feature should be implemented by adding __class_getitem__ methods which return self.

    The patch is trivial but requires a few lines of C code for C Accelerated CTask and CFuture as well as updating Python code.

    A volunteer is welcome!

    @asvetlov asvetlov added 3.9 only security fixes topic-asyncio easy labels Dec 5, 2019
    @gvanrossum
    Copy link
    Member

    In principle I think this is a good idea.

    If this was user code, we would inherit from typing.Generic. I understand you wanting to avoid the overhead of that. But will it work correctly at runtime with other typing constructors? I guess __annotations__ will not show the generic type's parameter. Will anybody care?

    Maybe we need to walk through some detailed examples.

    @asvetlov
    Copy link
    Contributor Author

    asvetlov commented Dec 5, 2019

    I thought __class_getitem__ was invented exactly to simplify generic types support.

    The only thing that confuses me an example from PEP-560:

    class MyList:
        def __getitem__(self, index):
            return index + 1
        def __class_getitem__(cls, item):
            return f"{cls.__name__}[{item.__name__}]"

    It prevents from instantiating a generic on inheritance, e.g. the following code raises TypeError:

    class MyOtherList(MyList[int]):
        pass

    It would be nice if Ivan clarifies what is the best practice in this case.
    I think the method should return unmodified class, not a string.

    @gvanrossum
    Copy link
    Member

    Well, __class_getitem__ was added primarily to allow classes implemented in
    *C* to support "generics". This is helpful to support PEP-585. For classes
    written in Python I don't see the point.

    But I'll leave the rest of this to Ivan.

    @ilevkivskyi
    Copy link
    Member

    I see the point in using __class_getitem__ in Python classes too, we can probably start using a dummy method returning class object itself now. Also PEP-585 already has a long list of candidates for "proper" __class_getitem__ support. Maybe we can add these classes to that list? Maybe it would make sense to also have PathLike there?

    @isidentical
    Copy link
    Sponsor Member

    I want to be a volunteer, if no one is working on this.

    @gvanrossum
    Copy link
    Member

    I'm actually missing context, so I will leave this up to you all.

    @miss-islington
    Copy link
    Contributor

    New changeset dec3672 by Miss Islington (bot) (Batuhan Taşkaya) in branch 'master':
    bpo-38978: Implement __class_getitem__ for asyncio objects (GH-17491)
    dec3672

    @asvetlov asvetlov closed this as completed Dec 7, 2019
    @asvetlov
    Copy link
    Contributor Author

    asvetlov commented Dec 7, 2019

    Done.
    I think that applying the same to PathLike makes sense as well, but it deserves another issue.

    @asvetlov
    Copy link
    Contributor Author

    asvetlov commented Dec 7, 2019

    Thanks, Batuhan!

    @isidentical
    Copy link
    Sponsor Member

    I think that applying the same to PathLike makes sense as well, but it deserves another issue.

    Yes, it looks like they are using that in typeshed. I'm opening another issue with a patch. Thanks for reminding that

    @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.9 only security fixes easy topic-asyncio
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants