classification
Title: _winreg.OpenKey() is documented with keyword arguments, but doesn't take them
Type: Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, stutzbach (2)
Priority: Keywords patch

Created on 2009-04-16 19:06 by stutzbach, last changed 2009-11-04 22:27 by brian.curtin.

Files
File name Uploaded Description Edit Remove
issue5774_20091104_v1.patch brian.curtin, 2009-11-04 22:27
Messages (2)
msg86038 - (view) Author: Daniel Stutzbach (stutzbach) Date: 2009-04-16 19:06
I noticed this in 2.6, but I imagine it affects 2.7, and 3.x as well.

The documentation for _winreg.OpenKey reads in part:

_winreg.OpenKey(key, sub_key[, res=0][, sam=KEY_READ])

However:

>>> import _winreg
>>> _winreg.OpenKey(_winreg.HKEY_CURRENT_USER, 'Software',
sam=_winreg.KEY_ALL_ACCESS)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: OpenKey() takes no keyword arguments

Probably the OpenKey implementation should be updated to use
PyArg_ParseTupleAndKeywords instead of PyArg_ParseTuple?
msg94906 - (view) Author: Brian Curtin (brian.curtin) Date: 2009-11-04 22:27
Attached is a patch against trunk r76107 which fixes OpenKey to take
keyword arguments as the documentation states. There is also a small fix
to test_winreg - the third param to OpenKey on line 45 is the `res`
positional param, which should always be zero according to the doc. The
parameter passed is supposed to be the `sam` parameter, which is now
passed as a kwarg. There is no actual change to the test results.


While looking at this, I'm not sure I see the need for OpenKeyEx - it
just points to OpenKey. At the very least, it's parameter list in the
documentation is incorrect.
History
Date User Action Args
2009-11-04 22:27:14brian.curtinsetfiles: + issue5774_20091104_v1.patch

nosy: + brian.curtin
messages: + msg94906

keywords: + patch
2009-04-16 19:06:11stutzbachcreate