Paul wrote: > 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. and later: > 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. :) 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4