classification
Title: Allow queue.Queue to be used in type annotations
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.10, Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: levkivskyi Nosy List: dreamsorcerer, ethan smith, gvanrossum, josh.r, levkivskyi, rhettinger, sproshev
Priority: normal Keywords:

Created on 2018-04-19 12:02 by sproshev, last changed 2020-06-14 05:26 by gvanrossum. This issue is now closed.

Messages (13)
msg315488 - (view) Author: Semyon Proshev (sproshev) Date: 2018-04-19 12:02
from queue import Queue

a: Queue[int]

This code throws a TypeError in runtime.
But its pyi stub allows to use it in such a way (https://github.com/python/typeshed/blob/master/stdlib/3/queue.pyi)

I'd suggest to update classes in queue module to allow them to be used in type annotations.
msg315527 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2018-04-20 17:38
None of the actual classes outside of the typing module support this either to my knowledge. You can't do:

    from collections import deque

    a: deque[int]

nor can you do:

    a: list[int]

Adding Queue to the typing module might make sense (feel free to edit it if that's what you're looking for), but unless something has changed in 3.7 (my local install is 3.6.4), it's never been legal to do what you're trying to do with queue.Queue itself with the original type, only with the special typing types that exist for that specific purpose.
msg315593 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2018-04-22 09:49
I think this issue appeared previously on typing tracker. The current recommendation is to escape problematic annotations with quotes:

q: 'Queue[int]'

I don't think it will be added to typing, because following this way typing will grow infinitely to include all generics in stdlib.

Another solution may be to add a simple `__class_getitem__` to `Queue` that will just return `cls` (so that we don't import `typing`). Although it will skip all the normal typing checks (so that `Queue[42]` will not raise at runtime), static type checkers like mypy will flag such errors. Guido, what do you think about such experiment?
msg315643 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-04-23 01:41
> Another solution may be to add a simple `__class_getitem__` to `Queue` 
> that will just return `cls`

I don't think it makes sense to let typing considerations start to spill into the rest of the standard library.  Either add support to typing or not.
msg315644 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-23 02:36
Disagree strongly. More later.

On Sun, Apr 22, 2018, 18:41 Raymond Hettinger <report@bugs.python.org>
wrote:

>
> Raymond Hettinger <raymond.hettinger@gmail.com> added the comment:
>
> > Another solution may be to add a simple `__class_getitem__` to `Queue`
> > that will just return `cls`
>
> I don't think it makes sense to let typing considerations start to spill
> into the rest of the standard library.  Either add support to typing or not.
>
> ----------
> nosy: +rhettinger
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33315>
> _______________________________________
>
msg315645 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-23 04:23
[Raymond]
> I don't think it makes sense to let typing considerations
> start to spill into the rest of the standard library.
> Either add support to typing or not.

We can't possibly add every stdlib class that's generic to typing.py -- it just doesn't scale. It also doesn't make sense to import everything from typing.

Arguably there are already some things in typing that don't belong there -- I'm thinking in particular of the 'io' and 're' classes. Those were a compromise to get the (in my opinion) most popular and fundamental classes quickly typed. But we definitely shouldn't continue down this path. Type annotations is here to stay (there's an increasing number of PEPs about it) and in the longer term we should support it directly in the appropriate stdlib modules. We're not ready to do that but we should start thinking about it.

Until we've gotten a firmer decision I don't think we should do one-offs, so I don't think Queue should be made generic right now, but we definitely shouldn't add it to typing. Users who are using typing should continue to consider themselves lucky to be early adopters and will occasionally pay a small price, such as putting the type in quotes or (for users on 3.7+) using "from __future__ import annotations".

PS. Raymond, please avoid pejoratives like "spill" in the future when talking about types.
msg315663 - (view) Author: Semyon Proshev (sproshev) Date: 2018-04-23 12:29
I had been thinking about `__class_getitem__` when the issue were created.

I suspected it's not difficult to implement and it follows PEP 560.
So I'm +1 for `__class_item__`, quotes and postponed evaluation are also ok.
msg315669 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-23 15:04
Could you please product a draft PR showing how that would work? It might
not be accepted right away but it would be useful to have.

On Mon, Apr 23, 2018, 05:29 Semyon Proshev <report@bugs.python.org> wrote:

>
> Semyon Proshev <s-proshev@ya.ru> added the comment:
>
> I had been thinking about `__class_getitem__` when the issue were created.
>
> I suspected it's not difficult to implement and it follows PEP 560.
> So I'm +1 for `__class_item__`, quotes and postponed evaluation are also
> ok.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33315>
> _______________________________________
>
msg316119 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2018-05-03 10:33
> Could you please product a draft PR showing how that would work? It might
not be accepted right away but it would be useful to have.

It is not 100% clear to whom this was addressed. Anyway, Semyon, if you don't have time, then I can make a simple PR, otherwise can you try doing it yourself?
msg316129 - (view) Author: Semyon Proshev (sproshev) Date: 2018-05-03 18:50
I'm not sure that I'll be able to make a PR quickly, so feel free to do it
msg371483 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-06-14 03:58
Can this can now be handled with "__class_getitem__ = classmethod(GenericAlias)"?
msg371484 - (view) Author: Ethan Smith (ethan smith) * Date: 2020-06-14 04:03
This was done in https://github.com/python/cpython/pull/19423

The implementation is as Raymond suggests:
https://github.com/python/cpython/blame/5aad027db9618f22f6fa2274e05dd50f928d2ed7/Lib/queue.py#L220

On Sat, Jun 13, 2020 at 8:58 PM Raymond Hettinger <report@bugs.python.org>
wrote:

>
> Raymond Hettinger <raymond.hettinger@gmail.com> added the comment:
>
> Can this can now be handled with "__class_getitem__ =
> classmethod(GenericAlias)"?
>
> ----------
> type:  -> behavior
> versions: +Python 3.10 -Python 3.5, Python 3.6, Python 3.7, Python 3.8
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33315>
> _______________________________________
>
msg371486 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-06-14 04:23
Leaving this for Guido or Ivan to decide whether this feature request is fully satisfied now.
History
Date User Action Args
2020-06-14 05:26:44gvanrossumsetstatus: open -> closed
resolution: fixed
versions: + Python 3.9
2020-06-14 04:23:29rhettingersetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg371486
2020-06-14 04:21:59rhettingersetstatus: open -> closed
resolution: fixed
stage: resolved
2020-06-14 04:03:16ethan smithsetmessages: + msg371484
2020-06-14 03:58:33rhettingersettype: behavior
messages: + msg371483
versions: + Python 3.10, - Python 3.5, Python 3.6, Python 3.7, Python 3.8
2020-06-12 22:16:26dreamsorcerersetnosy: + dreamsorcerer
2018-05-07 12:32:22levkivskyisetassignee: levkivskyi
2018-05-03 18:50:34sproshevsetmessages: + msg316129
2018-05-03 10:33:27levkivskyisetmessages: + msg316119
2018-04-25 11:16:42ethan smithsetnosy: + ethan smith
2018-04-23 15:04:18gvanrossumsetmessages: + msg315669
2018-04-23 12:29:41sproshevsetmessages: + msg315663
2018-04-23 04:23:55gvanrossumsetmessages: + msg315645
2018-04-23 02:36:16gvanrossumsetmessages: + msg315644
2018-04-23 01:41:08rhettingersetnosy: + rhettinger
messages: + msg315643
2018-04-22 09:49:08levkivskyisetnosy: + gvanrossum, levkivskyi
messages: + msg315593
2018-04-20 17:38:29josh.rsetnosy: + josh.r
messages: + msg315527
2018-04-19 12:02:56sproshevcreate