New winreg module really an improvement?

Ive just updated the test suite so that test_winreg2.py actually works. It appears that the new winreg.py module is still in a state of flux, but all work has ceased. The test for this module has lots of placeholders that are not filled in. Worse, the test code was checked in an obviously broken state (presumably "to be done", but guess who the bunny who had to do it was :-( Browsing the source made it clear that the module docstrings are still incomplete (eg "For information on the key API, open a key and look at its docstring."). As far as I can tell, there is no documentation in the library reference for this module (but the underlying _winreg module does have reasonable documentation) This is the first time I have had a serious look at the new winreg module, and the first time I have had to use it. I found it quite unintuitive, and it took me quite some time to update the test suite for what should have been a trivial case: Eg, the specific example I had a problem with was: key[value] Returns a result that includes the key index! This would be similar to a dictionary index _always_ returning the tuple, and the first element of the tuple is _always_ the key you just indexed. Has anyone else actually looked at or played with this, and still believe it is an improvement over _winreg? I personally find it unintuitive, and will personally continue to use _winreg. If we can't find anyone to complete it, document it, and stand up and say they really like it, I suggest we pull it. Still-can't-see-the-added-value-ly, Mark.

Mark Hammond writes:
It was supposed to be Paul Prescod, since it was his module.
Interesting; I'd understood from Paul that you'd given approval to this module.
Paul, this is very much on your plate to make Mark happy with it, or it goes! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

Interesting; I'd understood from Paul that you'd given approval to this module.
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. I also sent a copy of the .NET registry API at that time, suggesting that it may be a better reference API, and one that VB, C# etc programmers will (over time) be familiar with. [Now I can admit it was the .NET API :-] Then the checkin just appeared! The end result was that I was never quite happy, but I felt personally responsible as I didnt find the time to look into this. I felt that I couldn't object, as I had let the team down. I fear this may be a general symptom of the new flurry of activity; no-one with a real job can keep up with this list, meaning valuable feedback on many proposals is getting lost. For example, DigiCool have some obviously smart people, but they are clearly too busy to offer feedback on anything lately. That is a real shame, and a good resource we are missing out on.
Paul, this is very much on your plate to make Mark happy with it, or it goes!
The comments about the documentation etc are easy to fix. I am quite interested to hear from people like Gordon and Bill about their thoughts. I am willing to accept the fact that just because I don't personally like it doesn't mean it sucks ;-) Mark.

On Fri, Jul 28, 2000 at 03:04:53PM +1000, Mark Hammond wrote: [ Something about something changing very fast, not giving Mark the chance to react to it ]
Well, the same goes for Guido. Much though I liked the discussion about slices (and about augmented assignment) yesterday, it took me completely by suprise. And I'm not sure what the end result is, either. I don't even know whether it's finished or not, and it's not that easy to find out: it could be restin', pinin' for the fjords, or it could be nailed to its perch, it could be an ex-thread. And if it has ceased to be, well, it didn't amount to much, I think. Some opinions, and a simple (but effective, as far as I can tell) patch from Michael on one of the sub-issues. And I believe that's where PEPs are supposed to come in. They summarise the discussions, so that cool and smart people can look through it, see the proposal, see the pros and cons, and add their own. I'm not sure if it'll *work* like that, given that PEPs take some effort to create, and the format is still not too clear (at least, not to me.) And then there is the stuff that keeps popping up and isn't really PEPable: segfaults, tests failing, problem areas not covered by tests, unexpected behaviour noone has come around to fix or can figure out how to fix, etc. Maybe we need a TODO list, to store these issues ? Noone else is keeping track, I think, unless it's done in the Jitterbug buglist -- and I can't really work with jitterbug, myself. Items on the TODO list that stay on too long and start repetetive discussions are clearly candidates for PEPs, but others are just longstanding bugs that need to be properly investigated and fixed (probably elaborately) and noone disagrees with that. And if the 'fix' is non-obvious and involved, and generates too much discussion, it can always be PEPulated ;-) And if the TODO list needs a maintainer, someone that keeps track of all 'issues' that need closer examination, I'd be happy to volunteer. My idea would be to limit it to python-dev, unless someone forwards c.l.py traffic or other traffic that points out TODO-listable issues. (Or maybe SF has a good tool for this ? Not being a project admin, I've never seen the 'project manager', so I'm not sure if it has anything like a 'wishlist' ?) PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to sleep/eating.) You should try working for an ISP, too! <wink> -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

[Mark H]
[Thomas W]
Well, the same goes for Guido.
Not sure what you mean. I'm too busy to offer feedback on anything? Give me a break! I probably spend 4 hours reading and responding to python-dev each day.
It's still open. I was trying to respond to your own post where you considered a redesign of the augmented assignment bytecode. I still think the proposed redesign is a good one (always use LOAD a, LOAD b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.)
Don't worry too much about the format! Just write in a style that you think works for you. We're specifying the format to ensure that PEPs contain all the necessary information and are easily readable; I hope the rules aren't seen as stifling for PEP authors!
Actually, Jeremy is the officially appointed 2.0 release manager, and as far as I can tell he's doing a good job of keeping track of open issues. He's also working on transferring the JitterBug database to the SF Bug Tracker, so we can shut off Jitterbug.
The SF Bug Trackerwould work, I think.
4 hours travel time? That gets you across the country! This job must be real important for you...! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

On Fri, Jul 28, 2000 at 07:53:54AM -0500, Guido van Rossum wrote:
Well, the same goes for Guido.
Unless I misinterpreted you, *you yourself* said this, Guido. (I can look this up if you wish.) PEPs are there so you (and others, like me) don't have to follow the details of each discussion. I didn't mean to imply you (or anyone else) don't consider python-dev important enough to follow, absolutely not. I just meant that we can't expect you (or anyone) to give feedback on *everything*, given the pace of messages yesterday (or any of the other bursts of activity.) Reading all messages is something else than understanding the issues, considering them and proposing new solutions or new ways of viewing them.
I still think the proposed redesign is a good one (always use LOAD a, LOAD b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.)
So do I. I think thread-safety should be solved differently, even though I think it should be solved, somehow. ThreadSafeDict, with explicit grab/release lock ? :P But that was the other sub-thread. In this particular case, I was referring to the slicing thing, but I'm probably too impatient and urging on these issues. (Actually, I know I am. I'm just a tad worried things like this will go on and on and get lost and etc, etc, etc.) I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this weekend, I think, and removing the 2-argument opcodes etc.
Ah, yes, hadn't considered the 2.0 release manager, probably because I hadn't figured it as a job for him -- some of these issues go beyond 2.0. Never-saw-a-release-manager-before-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

You were commenting on Digital Creation's total absence. I am busy, but I am still very much involved in everything that goes on here, hence my reaction of "no fair!" That said, *nobody* can deal with 500 messages in one weekend, so the creations of PEPs should be received enthusiastically by all.
Reading all messages is something else than understanding the issues, considering them and proposing new solutions or new ways of viewing them.
And believe me, whereever I can, I do!
Library issue.
The slicing reorg is all pie-in-the-sky. Good for a post-2.0 PEP.
I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this weekend, I think, and removing the 2-argument opcodes etc.
Good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

I vaguely remember that I wasn't happy with the way this was handled either, but was too busy at the time to look into it. (I can't say whether I'm happy with the module or not, since I've never tried to use it. But I do feel unhappy about the process.) Note that Paul recently updated most of the docstrings, so he can't be blamed alone, and I'm sure fixes to the docstrings are welcome. Mark, could you spend some time explaining what you think should be changed in the module? I think it's not too late to change it -- after all there aren't any real users of the module out. (I note that Greg Ward chose the same route as you -- he uses _winreg, not winreg.) I vaguely remember that Paul Prescod's main gripe with the _winreg API was that it's not object-oriented enough -- but that seems his main gripe about most code these days. :-) Paul, how much experience with using the Windows registry did you have when you designed the new API? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

Guido van Rossum wrote:
I was also unhappy with the process but from a differEnt perspective. A new module appeared in the Python library: _winreg It was based on tried and true code: _winreg, but it's API had many placeholder arguments (where Microsoft had placeholder arguments) used function call syntax for things that were clearly methods (as Microsoft did for C), had an enumeration mechanism that seems, to me, be very unPythonic, had many undocumented features and constants, and the documented methods and properties often have weird Microsoft conventions (e.g. SetValueEx). The LaTeX documentation for the old winreg says of one method: "This is Lame Lame Lame, DO NOT USE THIS!!!" Now I am still working on new winreg. I got involved in a recursive project to avoid writing the docs twice in two different formats. We are still in the beta period so there is no need to panic about documentation yet. I would love nothing more than to hear that Windows registry handling is hereby delayed until Python 7 or until someone more interested wants to work on it for the love of programming. But if that is not going to happen then I will strongly advise against falling back to _winreg which is severely non-Pythonic.
In this case it wasn't a mild preference, it was a strong allergic reaction!
Paul, how much experience with using the Windows registry did you have when you designed the new API?
I use it off and on. There are still corners of _winreg that I don't understand. That's part of why I thought it needed to be covered up with something that could be fully documented. To get even the level of understanding I have, of the *original* _winreg, I had to scour the Web. The perl docs were the most helpful. :) Anyhow, Mark isn't complaining about me misunderstanding it, he's complaining about my mapping into the Python object model. That's fair. That's what we python-dev is for. As far as Greg using _winreg, my impression was that that code predates new winreg. I think that anyone who reads even just the docstrings for the new one and the documentation for the other is going to feel that the new one is at the very least more organized and thought out. Whether it is properly designed is up to users to decide. -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

Mark Hammond wrote:
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?
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 am quite interested to hear from people like Gordon and Bill about their thoughts.
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. 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. -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

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

FWIW, I ignored all the winreg modules, and all the debate about them. Why? Just because Mark's had been in use for years already, so was already battle-tested. There's no chance that any other platform will ever make use of this module, and given that its appeal is thus solely to Windows users, it was fine by me if it didn't abstract *anything* away from MS's Win32 API. MS's APIs are hard enough to understand without somebody else putting their own layers of confusion <0.9 wink> on top of them. May as well complain that the SGI-specific cd.open() function warns that if you pass anything at all to its optional "mode" argument, it had better be the string "r" (maybe that makes some kind of perverse sense to SGI weenies? fine by me if so). So, sorry, but I haven't even looked at Paul's code. I probably should, but-- jeez! --there are so many other things that *need* to get done. I did look at Mark's (many months ago) as part of helping him reformat it to Guido's tastes, and all I remember thinking about it then is "yup, looks a whole lot like the Windows registry API -- when I need it I'll be able to browse the MS docs lightly and use it straight off -- good!". So unless Mark went and did something like clean it up <wink>, I still think it's good.

Sorry but my contribution isn't going to help much with breaking the impasse. Registry code tends to be little lumps of complexity you don't touch once it is working. The Win32 Reg* API is quite ugly - RegCreateKeyEx takes/returns 10 parameters but you only normally want 3 and the return status and everyone asks for KEY_ALL_ACCESS until the installation testers tell you it fails for non-Administrators. So it would be good if the API was simpler and defaulted everything you don't need to set. But I only hack the registry about once a year with Python. So if its closer to the Win32 API then that helps me to use existing knowledge and documentation. When writing an urllib patch recently, winreg seemed OK. Is it complete enough? Are the things you can't do with it important for its role? IMO, if winreg can handle the vast majority of cases (say, 98%) then its a useful tool and people who need RegSetKeySecurity and similar can go to win32api. Do the distutils developers know how much registry access they need? Enough fence sitting for now, Neil

Just to clarify (or confuse) the issue:
Note that Neil was actually using _winreg - the exposure of the raw Win32 API. Part of my applying the patch was to rename the usage of "winreg" to "_winreg". Between the time of you writing the original patch and it being applied, the old "winreg" module was renamed to "_winreg", and Paul's new "winreg.py" was added. The bone of contention is the new "winreg.py" module, which urllib does _not_ use. Mark.

[Mark]
To try and get more productive: Bill, Gordon et al appear to have the sense to stay out of this debate.
Wish I had that much sense... I'm only +0 on the philosophy of a friendly Pythonic wrapper: the registry is only rarely the "right" solution. You need it when you have small amounts of persistent data that needs to be available to multiple apps and / or Windows. I actively discourage use of the registry for any other purposes. So making it easy to use is of very low priority for me. In addition, I doubt that a sane wrapper can be put over it. At first blush, it looks like a nested dict. But the keys are ordered. And a leaf is more like a list of tuples [(value, data), ]. But if you pull up regedit and look at how it's used, the (user- speak) "value" may be a (MS-speak) "key", "value" or "data". Just note the number of entries where a keyname has one (value, data) pair that consists of ("(Default)", "(value not set)"). Or the number where keyname must be opened, but the (value, data) pair is ("(Default)", something). (It doesn't help that "key" may mean "keyname" or "keyhandle", and "name" may mean "keyname" or "valuename" and "value" may mean "valuename" or "datavalue".) IOW, this isn't like passing lists (instead of FD_SETs) to select. No known abstract container matches the registry. My suspicion is that any attempt to map it just means the user will have to understand both the underlying API and the mapping. As a practical matter, it looks to me like winreg (under any but the most well-informed usage) may well leak handles. If so, that would be a disaster. But I don't have time to check it out. In sum: - I doubt the registry can be made to look elegant - I use it so little I don't really care - Gordon

Gordon McMillan wrote:
I would be very surprised if that was the case. Perhaps you can outline your thinking so that *I* can check it out. I claim that: _winreg never leaks Windows handles as long _winreg handle objects are destroyed. winreg is written entirely in Python and destroys _winreg handles as long as winreg key objects are destroyed. winreg key objects are destroyed as long as there is no cycle. winreg does not create cycles. Therefore, winreg does not leak handles. I'm 98% confident of each assertion...for a total confidence of 92%. -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

(reorganizing the important stuff to the top) Mark Hammond wrote:
Still-can't-see-the-added-value-ly,
I had no personal interest in an API for the windows registry but I could not, in good conscience, let the original one become the standard Python registry API. Here are some examples: (num_subkeys, num_values, last_modified ) = winreg.QueryInfoKey( key ) for i in range( num_values ): (name,value)=winreg.EnumValue( key, i ) if name==valuename: print "found" Why am I enumerating but not using the Python enumeration protocol? Why do I have to get a bogus 3-tuple before I begin enumerating? Where else are the words "Query" and "Enum" used in Python APIs? and winreg.SetValueEx( key, "ProgramFilesDir", None, winreg.REG_SZ, r"c:\programs" ) Note that the first argument is the key object (so why isn't this a method?) and the third argument is documented as bogus. In fact, in the OpenKey documentation you are requested to "always pass 0 please". 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. The truth is I would prefer NOT to work on winreg and leave both versions out of the library. But Unless someone else is willing to design and implement a decent API, I took that burden upon myself rather than see more weird stuff in the Python API. So the value add is: * uses Python iteration protocol * uses Python mapping protocol * uses Python method invocation syntax * uses only features that will be documented * does not expose integers as object handles (even for HKLM etc.) * uses inspectable, queryable objects even as docstrings * has a much more organized module dictionary (do a dir( _winreg)) If you disagree with those principles then we are in trouble. If you have quibbles about specifics then let's talk.
The tests ran fine on my machine. Fred had to make minor changes before he checked it in for me because of module name changes. It's possible that he mistyped a search and replace or something...or that I had a system dependency. Since I changed jobs I no longer have access to Visual C++ and have not had luck getting GCC to compile _winreg. This makes further testing difficult until someone cuts a Windows binary build of Python (which is perpetually imminent). The test cases are not all filled in. The old winreg test tested each method on average one time. The new winreg tries harder to test each in a variety of situations. Rather than try to keep all cases in my head I created empty function bodies. Now we have clear documentation of what is done and tested and what is to be tested still. Once an alpha is cut, (or I fix my compiler situation) I can finish that process.
The docstrings are not complete, but they are getting better and the old winreg documentation was certainly not complete either! I admit I got into a little bit of recursive projects wherein I didn't want to write the winreg, minidom, SAX, etc. documentation twice so I started working on stuff that would extract the docstrings and generate LaTeX. That's almost done and I'll finish up the documentation. That's what the beta period is for, right?
There is a very clearly labelled (and docstring-umented) getValueData method: key.getValueData("FOO") That gets only the value. Surely that's no worse than the original: winreg.QueryValue( key, "FOO" ) If this is your only design complaint then I don't see cause for alarm yet. Here's why I did it that way: You can fetch data values by their names or by their indexes. If you've just indexed by the name then of course you know it. If you've just fetched by the numeric index then you don't. I thought it was more consistent to have the same value no matter how you indexed. Also, when you get a value, you should also get a type, because the types can be important. In that case it still has to be a tuple, so it's just a question of a two-tuple or a three-tuple. Again, I thought that the three-tuple was more consistent. Also, this is the same return value returned by the existing EnumValue function.
I agree that it needs more review. I could not get anyone interested in a discussion of how the API should look, other than pointing at old threads. You are, of course, welcome to use whatever you want but I think it would be productive to give the new API a workout in real code and then report specific design complaints. If others concur, we can change it. -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

Paul wrote:
and later:
I believe this is the crux of the problem. Your only mistake was that you criticized and then tried to redesign a (poorly designed) API that you weren't intimately familiar with. My boss tries to do this occasionally; he has a tendency to complain that my code doesn't contain enough classes. I tell him to go away -- he only just started learning Python from a book that I've never seen, so he wouldn't understand... Paul, I think that the best thing to do now is to withdraw winreg.py, and to keep (and document!) the _winreg extension with the understanding that it's a wrapper around poorly designed API but at least it's very close to the C API. The leading underscore should be a hint that this is not a module for every day use. Hopefully someday someone will eventually create a set of higher level bindings modeled after the Java, VB or C# version of the API. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

guido wrote:
how about letting _winreg export all functions with their win32 names, and adding a winreg.py which looks some- thing like this: from _winreg import * class Key: .... HKEY_CLASSES_ROOT = Key(...) ... where the Key class addresses the 80% level: open keys and read NONE/SZ/EXPAND_SZ/DWORD values (through a slightly extended dictionary API). in 2.0, add support to create keys and write values of the same types, and you end up supporting the needs of 99% of all applications.
Hopefully someday someone will eventually create a set of higher level bindings modeled after the Java, VB or C# version of the API.
how about Tcl? I'm pretty sure their API (which is very simple, iirc) addresses the 99% level... </F>

Fredrik Lundh wrote:
To me, that would defeat the purpose. Have you looked at the "*" exported by _winreg? The whole point is to impose some organization on something that is totally disorganized (because that's how the C module is). -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

Guido van Rossum wrote:
I don't think that this has been demonstrated. We have one complaint about one method from Mark and silence from everyone else (and about everything else). The Windows registry is weird in its terminology, but it isn't brain surgery. Yes, I had to do some research on what various things do but I expect that almost anyone would have had to do that. Some of the constants in the module are meant to be used with functions that are not even exposed in the module. This indicates to me that nobody has clearly thought out all of the details (and also that _winreg is not a complete binding to the API). I probably understand the original API as well as anyone and more than most, by now. Anyhow, the list at the bottom should demonstrate that I understand the API at least as well as the Microsoftie that invented the .NET API for Java, VB and everything else.
Hopefully someday someone will eventually create a set of higher level bindings modeled after the Java, VB or C# version of the API.
Mark sent me those specs and I believe that the module I sent out *is* very similar to that higher level API. Specifically (>>> is Python version) Equals (inherited from Object)
__cmp__
key.Name
key.name
key.SubKeyCount
len( key.getSubkeys() )
key.ValueCount
len( key.getValues() )
Close
key.close()
CreateSubKey
key.createSubkey()
DeleteSubKey
key.deleteSubkey()
DeleteSubKeyTree
(didn't get around to implementing/testing something like this)
DeleteValue
key.deleteValue()
GetSubKeyNames
key.getSubkeyNames()
GetValue
key.getValueData()
GetValueNames
key.getValueNames()
OpenRemoteBaseKey
key=RemoteKey( ... )
OpenSubKey
key.openSubkey
SetValue
key.setValue()
ToString
str( key )
My API also has some features for enumerating that this does not have. Mark has a problem with one of those. I don't see how that makes the entire API "unintuitive", considering it is more or less a renaming of the .NET API. -- Paul Prescod - Not encumbered by corporate consensus "I don't want you to describe to me -- not ever -- what you were doing to that poor boy to make him sound like that; but if you ever do it again, please cover his mouth with your hand," Grandmother said. -- John Irving, "A Prayer for Owen Meany"

OK. Fine. You say your module is great. The Windows weenies here don't want to touch it with a ten-foot pole. I'm not going to be able to dig all the way to the truth here -- I don't understand the Registry API at all. I propose that you and Mark Hammond go off-line and deal with Mark's criticism one-on-one, and come back with a compromise that you are both happy with. I don't care what the compromise is, but both of you must accept it. If you *can't* agree, or if I haven't heard from you by the time I'm ready to release 2.0b1 (say, end of August), winreg.py bites the dust. I realize that this gives Mark Hammond veto power over the module, but he's a pretty reasonable guy, *and* he knows the Registry API better than anyone. It should be possible for one of you to convince the other. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
participants (10)
-
Fred L. Drake, Jr.
-
Fredrik Lundh
-
Gordon McMillan
-
Guido van Rossum
-
Mark Hammond
-
Mark Hammond
-
Neil Hodgson
-
Paul Prescod
-
Thomas Wouters
-
Tim Peters