Proposal: Registry access for Python on Windows
I propose to include functions to access the windows registry into the python 1.6 core. I have thrown together some code which I will post hopefully tomorrow, but I would like to hear some comments before. ---------------------------------------------------------------------- winreg - registry access module Constants: HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_USERS - bases of registry KEY_READ, KEY_WRITE, KEY_ALL_ACCESS - access rights REG_SZ, REG_DWORD, REG_BINARY - typecodes for values Exception: error - raised when a function fails. Will usually contain a windows error code and a textual description. Functions: OpenKey (base, subkey, [, rights=KEY_READ]) -> integer Opens an existing key with the specified access rights and returns an integer handle. The handle must be closed by a call to CloseKey(). CreateKey (base, subkey [, sam=KEY_ALL_ACCESS]) -> integer Creates a new subkey or opens an exsiting one and returns an integer handle. base must be one of the HKEY_ constants or an integer handle. The handle must be closed by a call to CloseKey(). CloseKey (handle) Closes a key handle. EnumValues (handle, subkey) -> sequence Returns a sequence containing name, value, typecode triples for each existing value. EnumKeys (handle, subkey) -> sequence Returns a sequence containing the names of all subkeys. QueryValue (handle, subkey) -> tuple Returns a tuple containing name, value and typecode. SetValue (handle, name, typecode, value) Sets the value of a name to value. value must be a string for REG_SZ or REG_BINARY, an integer for REG_DWORD. DeleteValue (handle, valuename) Deletes the value. DeleteKey (handle, name [,recursive=0) Deletes the named key if no subkeys exist. If recursive is given as a true value, subkeys are recursively deleted. This is done with Reg* calls, NOT with SHDeleteKey and SHDeleteEmptyKey functions, so should work under any flavor of NT and Win9x. Note: To use the SetValue and Delete* functions, the key must have been opened with KEY_WRITE_ACCESS or KEY_ALL_ACCESS. ---------------------------------------------------------------------- Open Questions: Is the recursive-flag for DeleteKey() too dangerous? Should I switch from an integer handle to a full blown python-object, which would call CloseKey() automatically in the destructor? A higher level interface would be nice, but this should probably implemented on top of this module in python. Comments appreciated! Thomas Heller ION-TOF GmbH
I propose to include functions to access the windows registry into the python 1.6 core.
I have thrown together some code which I will post hopefully tomorrow, but I would like to hear some comments before.
---------------------------------------------------------------------- winreg - registry access module
Constants: HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_USERS - bases of registry KEY_READ, KEY_WRITE, KEY_ALL_ACCESS - access rights REG_SZ, REG_DWORD, REG_BINARY - typecodes for values
Exception: error - raised when a function fails. Will usually contain a windows error code and a textual description.
Functions: OpenKey (base, subkey, [, rights=KEY_READ]) -> integer Opens an existing key with the specified access rights and returns an integer handle. The handle must be closed by a call to CloseKey().
CreateKey (base, subkey [, sam=KEY_ALL_ACCESS]) -> integer Creates a new subkey or opens an exsiting one and returns an integer handle. base must be one of the HKEY_ constants or an integer handle. The handle must be closed by a call to CloseKey().
CloseKey (handle) Closes a key handle.
EnumValues (handle, subkey) -> sequence Returns a sequence containing name, value, typecode triples for each existing value.
EnumKeys (handle, subkey) -> sequence Returns a sequence containing the names of all subkeys.
QueryValue (handle, subkey) -> tuple Returns a tuple containing name, value and typecode.
SetValue (handle, name, typecode, value) Sets the value of a name to value. value must be a string for REG_SZ or REG_BINARY, an integer for REG_DWORD.
DeleteValue (handle, valuename) Deletes the value.
DeleteKey (handle, name [,recursive=0) Deletes the named key if no subkeys exist. If recursive is given as a true value, subkeys are recursively deleted. This is done with Reg* calls, NOT with SHDeleteKey and SHDeleteEmptyKey functions, so should work under any flavor of NT and Win9x.
Note: To use the SetValue and Delete* functions, the key must have been opened with KEY_WRITE_ACCESS or KEY_ALL_ACCESS. ---------------------------------------------------------------------- Open Questions: Is the recursive-flag for DeleteKey() too dangerous? Should I switch from an integer handle to a full blown python-object, which would call CloseKey() automatically in the destructor? A higher level interface would be nice, but this should probably implemented on top of this module in python.
Comments appreciated!
As long as we're redesigning the API and not just copying the registry access functions fromn win32api, shouldn't this be made a little bit more OO? Things that return a handle should return an object, and things taking a handle should be methods of that object. Also, the structured return values should probably be turned into objects with attributes. It might be acceptable to do this as a Python wrapper; in that case perhaps the C module should be called _winreg. --Guido van Rossum (home page: http://www.python.org/~guido/)
Thomas Heller wrote:
I propose to include functions to access the windows registry into the python 1.6 core.
I have thrown together some code which I will post hopefully tomorrow, but I would like to hear some comments before.
[snip API - which appears to be a fairly low level wrap]
Open Questions: Is the recursive-flag for DeleteKey() too dangerous?
As long as it defaults to non-recursive, it's fine by me.
Should I switch from an integer handle to a full blown python-object, which would call CloseKey() automatically in the destructor?
Absodefiposilutely Yes. Not so sure you need typecode. There are 10 types defined, but most tools only do 3 (string, dword and binary) and most usage is of 2 (dword and string - which can hold binary data). So I'd think you could infer pretty safely. Actually, I guess this boils down to intent - "Python as a complete registry tool" would require all the types, but "Python can use the registry" could automatically use dword or string, as appropriate. - Gordon
I propose to include functions to access the windows registry into the python 1.6 core.
Agreed!
I have thrown together some code which I will post hopefully tomorrow, but I would like to hear some comments before.
---------------------------------------------------------------------- winreg - registry access module
Im not convinced that we need either a) a new implementation, or b) a new API. I would propose that we use the existing registry access functions from win32api - as I didnt code them, Im not suggesting this due to my own ego. The reasons for my beliefs are: * The new API does not add any new value. The only changes I can see are that OpenKey() has had a reserved value dropped and QueryValue() has an extra redundant result. Indeed the new API does not appear a new API at all, so should be clearly stated if indeed it is (and in which case, exactly what the changes are) or be documented as a pythonic wrapping of the existing win32 registry API. Further, there is some useful functionality dropped. * Well tested. There are some obscure rules and code that experience has shown we need. It would be a shame to reinvent those wheels. It has taken a few years to get it "just right", and this was an implementation by people who know their stuff! Why not take the existing code as it stands (which _does_ include an auto-closing key) and add a new .py wrapper? At least Python will have a "complete, but low-level" registry API, and a higher level "easier to use, but maybe not complete" layer implemented in Python. Indeed, Guido has stated that the existing win32api functions would be suitable for the core. However, the issue is the "coding style" - and I admit that if I knew exectly what that meant I would make the change - eg, if it only means renaming the identifiers it would be trivial - however, it would also appear to be excessively anal, so Im sure there is more to it than that :-) And-I-think-I-will-stay-out-of-the-ternary-debate-ly, Mark.
Im not convinced that we need either a) a new implementation, or b) a new API.
I would propose that we use the existing registry access functions from win32api - as I didnt code them, Im not suggesting this due to my own ego. The reasons for my beliefs are:
* The new API does not add any new value. The only changes I can see are that OpenKey() has had a reserved value dropped and QueryValue() has an extra redundant result. Indeed the new API does not appear a new API at all, so should be clearly stated if indeed it is (and in which case, exactly what the changes are) or be documented as a pythonic wrapping of the existing win32 registry API. Further, there is some useful functionality dropped.
* Well tested. There are some obscure rules and code that experience has shown we need. It would be a shame to reinvent those wheels. It has taken a few years to get it "just right", and this was an implementation by people who know their stuff!
Why not take the existing code as it stands (which _does_ include an auto-closing key) and add a new .py wrapper? At least Python will have a "complete, but low-level" registry API, and a higher level "easier to use, but maybe not complete" layer implemented in Python.
Sounds good to me.
Indeed, Guido has stated that the existing win32api functions would be suitable for the core. However, the issue is the "coding style" - and I admit that if I knew exectly what that meant I would make the change - eg, if it only means renaming the identifiers it would be trivial - however, it would also appear to be excessively anal, so Im sure there is more to it than that :-)
I only vaguely recollect what caused me to object against the coding style, but I think it was a lot of little things: // comments, lines longer than 78 chars, unusual indentation style. It was also somehow requiring C++ (everything in the core is plain C). I tried to do a style conversion myself, but found it very painful -- plus there were some dependencies on other files or modules that seemed to require me to pull in a lot of other things besides win32api.c. However, the registry functions are only a tiny piece of win32api -- they could probably be cut out of win32api and moved into something I would tentatively call win32reg (unless that's already an existing name), which could then be cleaned up much easier than all of win32api. I still think that it can be done, but evidently it takes someone besides me and Mark to do it. --Guido van Rossum (home page: http://www.python.org/~guido/)
I only vaguely recollect what caused me to object against the coding style, but I think it was a lot of little things: // comments, lines longer than 78 chars, unusual indentation style. It was also somehow requiring C++ (everything in the core is plain C). I tried to do a style conversion myself, but found it very painful -- plus there were some dependencies on other files or modules that seemed to require me to pull in a lot of other things besides win32api.c.
OK - that is a good enought list for me to get started. If no one else steps up within a week I will make an attempt at a module that meets these requirements.... Mark.
[Thomas]
I propose to include functions to access the windows registry into the python 1.6 core. [Mark]
Agreed!
Fine. Thats the _main_ purpose of the proposal.
winreg - registry access module
Im not convinced that we need either a) a new implementation, or b) a new API.
I would propose that we use the existing registry access functions from win32api - as I didnt code them, Im not suggesting this due to my own ego. The reasons for my beliefs are:
* The new API does not add any new value. The only changes I can see are that OpenKey() has had a reserved value dropped and QueryValue() has an extra redundant result. The redundant result value was a typo in the proposal. Indeed the new API does not appear a new API at all, so should be clearly stated if indeed it is (and in which case, exactly what the changes are) or be documented as a pythonic wrapping of the existing win32 registry API. Further, there is some useful functionality dropped.
I posted my proposal to start the discussion - so far it has been successfull - not as the final specification for the api. I admit: it has been too low level. I have posted (and implemented) a new proposal describing a more high level interface. In this I followed Gordon's suggestion: Provide the minimum needed. If one wants to do more special things, one probably needs your win32 extensions anyway.
* Well tested. There are some obscure rules and code that experience has shown we need. It would be a shame to reinvent those wheels.
It has taken a few years to get it "just right", and this was an implementation by
Already too late! (Programming is fun :-) (Is competition good ?) people
who know their stuff!
The only obscure code I can see (having looked at win32api source AFTER writing my code) is the handling of REG_MULTI_SZ. These are returned as one normal string with embedded NULL bytes by my implementation. BTW: This is also how regedit.exe (but not regedt32) handles these.
Why not take the existing code as it stands (which _does_ include an auto-closing key) and add a new .py wrapper? At least Python will have a "complete, but low-level" registry API, and a higher level "easier to use, but maybe not complete" layer implemented in Python.
Indeed, Guido has stated that the existing win32api functions would be suitable for the core.
However, the issue is the "coding style" - and I admit that if I knew exectly what that meant I would make the change - eg, if it only means renaming the identifiers it would be trivial - however, it would also appear to be excessively anal, so Im sure there is more to it than that :-) It seems (but I may be wrong) that my coding style is nearer to Guido's
Don't you think that the raw Win32 api functions are much too low level to belong into core python? How should they be documented? Pointers to msdn.microsoft.com? than that of win32api. Regards, Thomas
[Thomas writes]
I admit: it has been too low level. I have posted (and implemented) a new proposal describing a more high level interface.
Your high-level interface looks fine (except it should be coded in Python ;-)
In this I followed Gordon's suggestion: Provide the minimum needed.
I took that to mean "for the high-level interface"
If one wants to do more special things, one probably needs your win32 extensions anyway.
Im not really convinced about this. I would still rather see the complete win32api registry support added, seeing as the code exists.
Already too late! (Programming is fun :-) (Is competition good ?)
Of course it is good - it means I will get my implementation done quicker now ;-)
Don't you think that the raw Win32 api functions are much too low level to belong into core python? How should they be documented?
You said you have seen the sources, so you should have seen there is also copious documentation - Im converting them to docstrings. Mark.
participants (4)
-
Gordon McMillan -
Guido van Rossum -
Mark Hammond -
Thomas Heller