> Im not convinced that we need either a) a new implementation, or b) a new > API. > > 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. 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, exactly > what the changes are) or be documented as a pythonic wrapping of the > existing win32 registry API. Further, there is some useful functionality > dropped. > > * Well tested. There are some obscure rules and code that experience has > shown we need. It would be a shame to reinvent those wheels. It has taken > a few years to get it "just right", and this was an implementation by people > who know their stuff! > > 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. Sounds good to me. > Indeed, Guido has stated that the existing win32api functions would be > suitable for the core. 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, it > would also appear to be excessively anal, so Im sure there is more to it > than that :-) I only vaguely recollect what caused me to object against the coding style, but I think it was a lot of little things: // comments, lines longer than 78 chars, unusual indentation style. It was also somehow requiring C++ (everything in the core is plain C). I tried to do a style conversion myself, but found it very painful -- plus there were some dependencies on other files or modules that seemed to require me to pull in a lot of other things besides win32api.c. However, the registry functions are only a tiny piece of win32api -- they could probably be cut out of win32api and moved into something I would tentatively call win32reg (unless that's already an existing name), which could then be cleaned up much easier than all of win32api. I still think that it can be done, but evidently it takes someone besides me and Mark to do it. --Guido van Rossum (home page: http://www.python.org/~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