[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)  # False == 0, still lock=True

>>> multiprocessing.Value("I", lock=False)
c_uint(0)

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 multiprocessing.sharedctypes, maybe it was one of the others that 
caught your attention instead?

I wished that block/blocking had turned out to be a keyword-only argument in 
multiprocessing.Lock as part of issue23484, which I immediately thought of when 
reading this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com




[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 (in Lib/multiprocessing/sharedctypes.py)

def Value(typecode_or_type, *args, lock=True, ctx=None):

I'd suggest to remove that part of the documentation in 3.4+. We can also make 
it a keyword-only argument in Python 3.6. That will make the API more similar 
with 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array

--
assignee: docs@python
components: Documentation
messages: 251196
nosy: berker.peksag, davin, docs@python, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: lock of multiprocessing.Value is not a keyword-only argument
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com