This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Implement __class_getitem__ for Future, Task, Queue
Type: Stage: resolved
Components: asyncio Versions: Python 3.9
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, asvetlov, gvanrossum, levkivskyi, lukasz.langa, miss-islington, yselivanov
Priority: normal Keywords: easy, easy (C), patch

Created on 2019-12-05 12:53 by asvetlov, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 17491 merged BTaskaya, 2019-12-07 10:43
Messages (11)
msg357848 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2019-12-05 12:53
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!
msg357854 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-12-05 14:55
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.
msg357857 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2019-12-05 16:01
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]):

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.
msg357864 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-12-05 16:34
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.
msg357875 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-12-05 18:04
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?
msg357876 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-05 18:15
I want to be a volunteer, if no one is working on this.
msg357885 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-12-05 19:03
I'm actually missing context, so I will leave this up to you all.
msg357965 - (view) Author: miss-islington (miss-islington) Date: 2019-12-07 11:05
New changeset dec367261e7e2bb4dd42feeb58031abed2ade683 by Miss Islington (bot) (Batuhan Taşkaya) in branch 'master':
bpo-38978: Implement __class_getitem__ for asyncio objects (GH-17491)
msg357966 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2019-12-07 11:06
I think that applying the same to PathLike makes sense as well, but it deserves another issue.
msg357967 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2019-12-07 11:07
Thanks, Batuhan!
msg357977 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-07 15:49
> 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
Date User Action Args
2022-04-11 14:59:24adminsetgithub: 83159
2019-12-07 15:49:04BTaskayasetmessages: + msg357977
2019-12-07 11:07:09asvetlovsetmessages: + msg357967
2019-12-07 11:06:49asvetlovsetmessages: + msg357966
2019-12-07 11:05:46asvetlovsetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2019-12-07 11:05:12miss-islingtonsetnosy: + miss-islington
messages: + msg357965
2019-12-07 10:43:03BTaskayasetkeywords: + patch
stage: patch review
pull_requests: + pull_request16969
2019-12-05 19:03:08gvanrossumsetmessages: + msg357885
2019-12-05 18:15:25BTaskayasetnosy: + BTaskaya
messages: + msg357876
2019-12-05 18:04:30levkivskyisetnosy: + lukasz.langa
messages: + msg357875
2019-12-05 16:34:22gvanrossumsetmessages: + msg357864
2019-12-05 16:01:20asvetlovsetmessages: + msg357857
2019-12-05 14:55:53gvanrossumsetmessages: + msg357854
2019-12-05 14:29:24serhiy.storchakasetnosy: + gvanrossum, levkivskyi
2019-12-05 12:53:23asvetlovcreate