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/)

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.

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 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.