> I've just had a chance to look at the winreg module. I think that it is > too low-level. I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. I successfully argued there should be _2_ modules for Python - the raw low-level API, which guarantees you can do (almost) anything. A higher-level API could cover the 80% of cases. It is probably worth getting in touch with Thomas - he may be able to dig up his proposed high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - otherwise you will be wondering WTF I am on about :] I was very keen to ensure the win32api code was used as the low-level API, simply because it has been well tested and used. We _know_ it has no significant limitations. Im happy to support a high-level API, but didnt have the inclination to provide one. Every one I have seen and every one I have tried to design has started to fall-apart under real-world use - Ive needed to revert back to the low-level. > There are also bogus parameters that Microsoft hasn't got around to > assigning values to, undocumented constants and so forth. My favorite is > "WHOLE_HIVE_VOLATILE". This is exactly my concern with a high-level API - you cant hope to capture all this - especially the undocumented ones - so having a low-level API means you can do anything, even stuff never dreamt of by the high-level designer. I have no real problem with your proposed design, as long as it it written in Python, _using_ the low-level API. It could be called "registry" or I would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module to be called "winreg.py" Mark.
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