[Distutils] Re: [Python-Dev] Proposal: Registry access for Python on Windows
Thu, 3 Feb 2000 14:26:39 +0100
> > I propose to include functions to access the windows registry
> > into the python 1.6 core.
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
> 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,
> what the changes are) or be documented as a pythonic wrapping of the
> existing win32 registry API. Further, there is some useful functionality
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.
Already too late! (Programming is fun :-) (Is competition good ?)
> It has taken
> a few years to get it "just right", and this was an implementation by
> 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.
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?
> 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,
> 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
than that of win32api.