Implement __class_getitem__ for Future, Task, Queue

[asvetlov]

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]

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!

[gvanrossum]

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]

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]

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]

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]

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

[gvanrossum]

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

[miss-islington]

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]

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

[asvetlov]

Thanks, Batuhan!

[isidentical]

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