[Python-Dev] New winreg module really an improvement?

[Mark Hammond]

I am going to try very hard to avoid antagonistic statements - it doesnt
help anyone or anything when we are so obviously at each others throats.

Let me start by being conciliatory:  I do appreciate the fact that you made
the effort on the winreg module, and accept it was done for all the right
reasons.  The fact that I dont happen to like it doesnt imply any personal
critisism - I believe we simply have a philosophical disagreement.  But
then again, they are the worst kinds of disagreements to have!

> > Actually, it was more more along the lines of me promising to
> spend some
> > time "over the next few days", and not getting to it.
> However, I believe
> > it was less than a week before it was just checked in.
>
> It was checked in the day before the alpha was supposed to go out. I
> thought that was what you wanted! On what schedule would you have
> preferred us to do it?

Im not sure, but one that allowed everyone with relevant input to give it.
Guido also stated he was not happy with the process.  I would have
preferred to have it miss the alpha than to go out with a design we are not
happy with.

> >From my point of view, it was the appearance of _winreg that prompted
> the "flurry of activity" that led to winreg. I would never have bothered
> with winreg if I were not responding to the upcoming "event" of the
> defacto standardization of _winreg. It was clearly designed (and I use
> the word loosely) by various people at Microsoft over several years --
> with sundry backwards and forwards compatibility hacks embedded.

Agreed.  However, the main problem was that people were assuming win32api
was around to get at the registry.  The win32api module's registry
functions have been around for _ages_.  None of its users have ever
proposed a more Pythonic API.  Thus I find it a little strange that someone
without much experience in the API should find it such an abomination,
while experienced users of the API were clearly happy (ok - maybe "happy"
isnt the right word - but no unhappy enough to complain :-)

If nothing else, it allows the proliferation of documentation on the Win32
API to apply to Python.  This is clearly not true with the new module.

This is also a good case for using the .NET API.  However, it still would
not provide Python indexing, iteration etc.  However, as I state below, Im
not convinced this is a problem.

> I'm all for slow and steady, deliberate design. I'm sorry _winreg was
> rushed but I could only work with the time I had and the interest level
> of the people around. Nobody else wanted to discuss it. Nobody wanted to
> review the module. Hardly anyone here even knew what was in the OLD
> module.

I dont belive that is fair.  As I said, plenty of people has used win32api,
and were sick of insisting their users install my extensions.  distutils
was the straw that broke the serpents back, IIRC.

It is simply the sheer volume of people who _did_ use the win32api registry
functions that forced the new winreg module.

The fact that no one else wanted to discuss it, or review it, or generally
seemed to care should have been indication that the new winreg was not
really required, rather than taken as proof that a half-baked module that
has not had any review should be checked in.

> I am too. I would *also* be interested in hearing from people who have
> not spent the last five years with the Microsoft API because _winreg was
> a very thin wrapper over it and so will be obvious to those who already
> know it.

Agreed - but it isnt going to happen.  There are not enough people on this
list who are not experienced with Windows, but also intend getting that
experience during the beta cycle.  I hope you would agree that adding an
experimental module to Python simply as a social experiment is not the
right thing to do.  Once winreg is released, it will be too late to remove,
even if the consesus is that it should never have been released in the
first place.

> I have the feeling that an abstraction over the APIs would never be as
> "comfortable" as the Microsoft API you've been using for all of these
> years.

Again agreed - although we should replace the "you've" with "you and every
other Windows programmer" - which tends to make the case for _winreg
stronger, IMO.

Moving to the second mail:

> All of that was appropriate when winreg was documented "by reference" to
> the Microsoft documentation but if it is going to be a real, documented
> module in the Python library then the bogus MS junk should go.

I agree in principal, but IMO it is obvious this will not happen.  It hasnt
happened yet, and you yourself have moved into more interesting PEPs.  How
do you propose this better documentation will happen?

> The truth is I would prefer NOT to work on winreg and leave both
> versions out of the library.

Me too - it has just cost me work so far, and offers me _zero_ benefit (if
anyone in the world can assume that the win32api module is around, it
surely must be me ;-).  However, this is a debate you need to take up with
the distutils people, and everyone else who has asked for registry access
in the core.  Guido also appears to have heard these calls, hence we had
his complete support for some sort of registry module for the core.

> So the value add is:
...
> If you disagree with those principles then we are in trouble. If you
> have quibbles about specifics then let's talk.

I'm afraid we are in a little trouble ;-)  These appear dubious to me.  If
I weigh in the number of calls over the years for a more Pythonic API over
the win32api functions, I become more convinced.

The registry is a tree structure similar to a file system.  There havent
been any calls I have heard to move the os.listdir() function or the glob
module to a more "oo" style?  I dont see a "directory" object that supports
Python style indexing or iteration.  I dont see any of your other benefits
being applied to Python's view of the file system - so why is the registry
so different?

To try and get more productive:  Bill, Gordon et al appear to have the
sense to stay out of this debate.  Unless other people do chime in, Paul
and I will remain at an impasse, and no one will be happy.  I would much
prefer to move this forward than to vent at each other regarding mails
neither of us can remember in detail ;-)

So what to do?  Anyone?  If even _one_ experienced Windows developer on
this list can say they believe "winreg" is appropriate and intuitive, I am
happy to shut up (and then simply push for better winreg documentation ;-)

Mark.