Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiprocessing: Value / Array with lock=False are not Sized #9898

Closed
prauscher opened this issue Mar 17, 2023 · 6 comments
Closed

multiprocessing: Value / Array with lock=False are not Sized #9898

prauscher opened this issue Mar 17, 2023 · 6 comments
Labels
stubs: false positive Type checkers report false errors

Comments

@prauscher
Copy link
Contributor

prauscher commented Mar 17, 2023

Hello everyone,

Consider the following code:

from multiprocessing import Array
from ctypes import c_char

a = Array(c_char, 128, lock=True)
print(len(a))  # this is fine

b = Array(c_char, 128, lock=False)
print(len(b))  # this is: Argument 1 to "len" has incompatible type "c_char"; expected "Sized"

To my untrained eye, the issue is with https://github.com/python/typeshed/blob/main/stdlib/multiprocessing/sharedctypes.pyi#L40 returning _CT while https://github.com/python/typeshed/blob/main/stdlib/multiprocessing/sharedctypes.pyi#L48 returns SynchronizedArray[Any]

Actually, Array does support __len__ even with lock=False and therefore is Sized. I'm quite sure there is a reason to return _CT instead for lock=False, but I do not know it and it probably should not have this side effect.

@srittau
Copy link
Collaborator

srittau commented Mar 17, 2023

I have no experience with sharedctypes, but this looks to be to be a simple bug: b should return _SomeArrayType[_CT], instead of c_char. At runtime, the type returned identifies as multiprocessing.sharedctypes.c_char_Array_128, but that type doesn't exist. I would think we need to defined a type-specific array type and use that. But maybe someone with more sharedctypes experience can chime in.

@srittau srittau added the stubs: false positive Type checkers report false errors label Mar 17, 2023
@Akuli
Copy link
Collaborator

Akuli commented Mar 17, 2023

I think it should be ctypes.Array[_CT]. It would be consistent with how the * operator is annotated, and the * operator is how you usually create an array type in ctypes:

>>> import ctypes
>>> ctypes.c_char * 128
<class '__main__.c_char_Array_128'>

@ankm20
Copy link
Contributor

ankm20 commented Mar 29, 2023

Can this be assigned to me?

@prauscher
Copy link
Contributor Author

Thanks @Akuli, i tested your suggestion by replacing _CT with ctypes.Array[_CT] in

def Array(self, typecode_or_type: type[_CT], size_or_initializer: int | Sequence[Any], *, lock: Literal[False]) -> _CT: ...

So while this would solve the issue, I'm not sure about possible side effects...

@srittau
Copy link
Collaborator

srittau commented Mar 11, 2024

You can always open an exploratory PR here. mypy_primer will test the change against quite a lot of projects, which helps us to judge the impact.

prauscher added a commit to prauscher/typeshed that referenced this issue Mar 11, 2024
could fix python#8799 and python#9898, but request review for side effects.
Without this change, static type checkers would treat `Value(ctypes.c_float, 0.0)` like `ctypes.c_float`, but `Value` offers a field `value` for storage
@prauscher
Copy link
Contributor Author

I created #11576 to test this change, maybe someone can help with review there?

@srittau srittau closed this as completed Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stubs: false positive Type checkers report false errors
Projects
None yet
Development

No branches or pull requests

4 participants