[issue25201] lock of multiprocessing.Value is not a keyword-only argument

2015-09-21 Thread Martin Panter
Martin Panter added the comment: I’m not familiar with this module, but I believe “lock” is indeed keyword-only. If you were to try a positional argument, it would be picked up as part of *args: >>> multiprocessing.Value("I") # Default to 0, lock=True >>> multiprocessing.Value("I", False)

[issue25201] lock of multiprocessing.Value is not a keyword-only argument

2015-09-21 Thread Berker Peksag
Berker Peksag added the comment: I didn't test it carefully. It was a mistake on my part :) But I think the function signature could be clearer by changing that part to "*, lock=True". -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed

[issue25201] lock of multiprocessing.Value is not a keyword-only argument

2015-09-21 Thread Davin Potts
Davin Potts added the comment: Berker: It looks to me like the docs are indeed in sync with the code on Value in that lock really is a keyword-only argument. It looks like it's been that way since at least 2.7 (I didn't look at earlier). There are enough other things in the

[issue25201] lock of multiprocessing.Value is not a keyword-only argument

2015-09-21 Thread Josh Rosenberg
Josh Rosenberg added the comment: Agreed. Having a named positional varargs argument makes subsequently defined arguments keyword only automatically. -- nosy: +josh.r ___ Python tracker

[issue25201] lock of multiprocessing.Value is not a keyword-only argument

2015-09-20 Thread Berker Peksag
New submission from Berker Peksag: >From >https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Value Note that lock is a keyword-only argument. But the signature of Value (in Lib/multiprocessing/context.py) def Value(self, typecode_or_type, *args, lock=True): and