GeezerVison

These were a bit controversial when @srittau added them, and he probably doesn't want them removed: #5346

Ah, thanks for the reference.

The other options are:

• Special-case __init__.pyi files in the flake8-pyi check (what I did originally, but @JelleZijlstra doesn't like that).
• Just # noqa all the ones in multiprocessing.
• Abandon the flake8-pyi check entirely.
• Something else?

I think this is somewhat of a "true positive". These type aliases are just weird: named as if they were private, intended to be public, not documented, not discoverable. But again, @srittau will probably disagree. I think we should wait for his input.

But again, @srittau will probably disagree. I think we should wait for his input.

Yeah of course, not going to merge without it :)

I think this comment is just outdated? As far as I can see, all these are classes in the implementation, at least in Python 3.7+. Was this maybe different in the past? In that case, I don't think we need the type aliases below.

They became functions in the stub at some point, but it was reverted.

Somehow I missed that you asked about the implementation, not about the stub. These are functions (actually methods) in the implementation:

>>> from multiprocessing import Queue
>>> Queue
<bound method BaseContext.Queue of <multiprocessing.context.DefaultContext object at 0x7f66f26d73d0>>

There is also an undocumented class that is different from the public and documented Queue:

>>> from multiprocessing.queues import Queue
>>> Queue
<class 'multiprocessing.queues.Queue'>

There's similarly e.g. a method multiprocessing.Event and a class multiprocessing.synchronize.Event.

This is what happens at runtime:

>>> import multiprocessing
>>> multiprocessing.Queue
<bound method BaseContext.Queue of <multiprocessing.context.DefaultContext object at 0x000002F32AF7E5C0>>
>>> multiprocessing.Queue[int]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'method' object is not subscriptable

So the stubs are a bit of a lie at the moment. As @Akuli says, the stubs were changed in #4289 so that they could match the runtime more closely, but then that was reverted in #4314 after Jukka complained in #4313.

The thing is, either way, I don't think having these aliases helps the situation much. To work around these issues, a user can probably just put multiprocessing.Queue in quotes in their annotations, or use from __future__ import annotations.

We should try to make them into functions again in the stubs and see the fallout, now that we have mypy_primer. Annotating something with muliprocessing.Queue, which is a function, is not something we should support.

I marked my previous comment as off-topic, as it doesn't belong at all to this PR. I somehow didn't see other people's comments that were posted before I wrote mine.

since the type aliases are connected to this, we should keep those that are alternatives to a function.

I don't really see how the aliases help, even the ones which are alternatives to a function.

Take multiprocessing.Lock -- multiprocessing.Lock is a method, but multiprocessing.synchronize.Lock is a class. If it's a choice between doing this:

from multiprocessing.synchronize import Lock
foo: Lock

or this:

from typing import TYPE_CHECKING
if TYPE_CHECKING:
    from multiprocessing import _LockType
foo: "_LockType"

Then, I find the first way much cleaner and more ergonomic. And, as @Akuli says in his minimized comment, we know none of the projects in mypy_primer are using these aliases.

Sorry for being unclear. Yes, if there is a valid type somewhere, like multiprocessing.synchronize.Lock, we don't need the alias. It's possible that this is true for all aliases, I didn't check.

_BarrierType, _BoundedSemaphoreType, _ConditionType, _EventType, _LockType, _RLockType and _SemaphoreType are all aliases to valid types in multiprocessing.synchronize.

_QueueType, _SimpleQueueType and _JoinableQueueType are all aliases to valid types in multiprocessing.queues.

So yeah, it's true for all the aliases :)