Guido wrote: > > Another possibility: we'd get a lot more mileage out of simply > > adding ctypes to the standard install. That would solve the > > immediate popen problem, let us get rid of _winreg entirely (and > > replace it with a pure Python version), and make future Win32 > > problems easier to solve. > > I don't know that a Python version of _winreg using ctypes would be > preferable over a C version. I'd expect it to be slower, less > readable than the C version, Really? I don't see how it could be less readable. For example: http://www.pythonapocrypha.com/WinReg.py (gets used like: import WinReg as WR key = r'HKEY_CLASSES_ROOT\CLSID\%s' % clsid WR.QSetValue(key, '', desc) WR.QSetValue(r'%s\ProgID' % key, '', progid) ... WR.DeleteKey(WR.HKEY_CLASSES_ROOT, r'CLSID\%s' % clsid) WR.DeleteKey(WR.HKEY_CLASSES_ROOT, r'AppID\%s' % clsid) ) It's not a completely fair comparison to _winreg.c since it implements only a few routines I use all the time and probably does less error checking, but it at least shows how simple it would be to create such a module (if nothing else, the 100 lines of Python versus 1000+ for the C version encourages contribution). > and more susceptible to the possibility of causing segfaults. I don't see how, but maybe I don't know enough about the registry. > (As for speed, I actually have a windows registry application where speed of access is important.) But surely that's the exception rather than the rule. Anyway, I'd be curious to see how much of a difference there is - in the end the same Windows APIs get called, so it boils down to the difference between ctypes API overhead versus Python/C API overhead. -Dave
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