Open hauntsaninja opened 4 years ago
I removed the good-first-issue label since some of these are fairly complicated to fix "right", see discussion in #4282
However, there are likely some easy fixes in here as well that do make good first issues! I'd recommend taking a look at any of the ones complaining about missing or differing arguments :-)
With respect to multiprocessing.Event
, the python docs define that as a class, but it is a method. So if you try
from multiprocessing import Event
myevent: Event = Event()
you get a mypy error, because multiprocessing.Event
is a function, not a class. If you leave out the type declaration, it is valid code.
Not sure if that means the typing in typeshed has to fix that, or if it is a documentation bug on the python side.
typeshed tries to follow the implementation, not the documentation. In this case the documentation is at least misleading.
typeshed tries to follow the implementation, not the documentation. In this case the documentation is at least misleading.
So where do we report the documentation issue?
See the conversation on #4313
Technically you could report this to bugs.python.org, but Python core devs are already aware of this. See https://bugs.python.org/issue19895 for example.
@Akuli thanks for the pointers. We can work around it by doing
from multiprocessing import Event
from multiprocessing.synchronize import Event as EventClass
myevent: EventClass = Event()
Maybe re-exporting the "proper" classes from multiprocessing
as _EventType
, _QueueType
etc. is the best solution.
Currently typeshed just says that Queue
is a class, even though it isn't, so you can write myqueue: Queue = Queue()
for example. As can be seen from #4313 etc, changing this now is probably not a good idea.
But for some reason, Event
and a few other things are functions in typeshed. Maybe we should make them look like classes as well, so that at least it's consistent, even if it lies?
We should not change those if they are already correct, and we should work towards fixing Queue
as well. Lies in typeshed always cause more problems than they solve, in my experience.
Is it possible to type a multiprocessing.Value
? I can't figure out how without making mypy fail.
There isn't a great way; how best to type it depends on how exactly you're using it. Also willing to bet that the stubs could be improved (e.g. looks like the lock
to Value should have a default value on the Literal[True] overload)
Is the code you're working on open source? That would help us, e.g. we could add it to https://github.com/hauntsaninja/mypy_primer
I'm not doing anything too special with it, here's a simple example that I don't know how to properly type (as written mypy will complain):
import multiprocessing
def target(counter: multiprocessing.Value):
counter += 1
if __name__ == "__main__":
from ctypes import c_int
counter = multiprocessing.Value(c_int)
ps = [multiprocessing.Process(target=target, args=(counter,)) for _ in range(5)]
for p in ps:
p.start()
for p in ps:
p.join()
print(counter)
Although in my actual code I'm using lock=False
. It's not open source unfortunately.
The precise type is probably multiprocessing.sharedctypes.SynchronizedBase[ctypes.c_int]
I also made the change I suggested in #8330, which means you'll get a much more precise return type. Right now in your snippet, counter just ends up as Any.
I think I found a blind spot? I upgraded mypy recently and now I get the following:
import ctypes
from multiprocessing import Array
a = Array(ctypes.c_char, 32)
with a.get_lock():
print(a.value)
> mypy a.py
a.py:6: error: "SynchronizedArray[c_char]" has no attribute "value" [attr-defined]
Found 1 error in 1 file (checked 1 source file)
Where the docs explicitly say "that an array of ctypes.c_char has value and raw attributes which allow one to use it to store and retrieve strings." (https://docs.python.org/3/library/multiprocessing.html?highlight=array#multiprocessing.Array)
For @madig s problem it looks like SynchronizedString
is lost in Array
-Constructor: While https://github.com/python/typeshed/blob/main/stdlib/multiprocessing/sharedctypes.pyi#L68 returns a SynchronizedString
, none of the Array
specifications will return SynchronizedString
.
The same seems to be true in https://github.com/python/typeshed/blob/main/stdlib/multiprocessing/sharedctypes.pyi#L66, so that
a = Value(ctypes.c_float, 0.0)
a.value = 1.0 # error: Incompatible types in assignment (expression has type "float", variable has type "c_float") [assignment]
I think both should be quite easy to fix, but the overloads of Value
and Array
keep getting bigger and bigger...
See #10319, I think that is the same issue
stubtest finds a number of issues with the existing multiprocessing stubs. PRs that work toward fixing these (if they need fixing) are welcome, even if they're small!