GeezerVison

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

I'm still not sure if we should do this. Even though lies in typeshed often result in problems, I think this is more of a "practicality beats purity" case, as being able to use multiprocessing.Event or multiprocessing.Queue as a type annotation has several advantages:

• It is what users of typeshed expect. This is important. Even though they aren't types at runtime, that likely isn't a problem in practice. For example, isinstance(some_object, multiprocessing.Queue) errors every time, instead of silently doing the wrong thing. Also, isinstance checks like that are much less common than type annotations.
• Not-what-you-would-expect things need documentation. A comment somewhere in typeshed's stub files does not suffice, and we don't really have a good place where the documentation would go.
• Type checkers don't give a good error message for using a function as a type annotation. If you should use multiprocessing._Event as the type annotation instead of multiprocessing.Event, then the error message you get when using multiprocessing.Event should clearly say so. But it doesn't. It should either explain the situation or point to the documentation, wherever it would be.

I'm strongly opposed to introducing more lies, especially in this case. For example, IDEs will report wrong signatures and the following will not report an error, but will fail at runtime:

from multiprocessing import Queue
class MyQueue(Queue): ...

There are probably more problems with lying, and often these problems are subtle and hard to spot for someone not knowing what's going on. On the other hand, using foo: Queue = Queue() is an immediate error and investigating that error will lead the use to the stubs and the correct solution.