[Python-Dev] New winreg module really an improvement? (original) (raw)

Mark Hammond MarkH@ActiveState.com
Tue, 1 Aug 2000 17:59:22 +1000

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.