Guido van Rossum <guido at python.org> writes: > 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, and more susceptible to the possibility > of causing segfaults. (As for speed, I actually have a windows > registry application where speed of access is important.) > > That doesn't mean I don't think ctypes is a good idea -- just that I > don't think applying it to _winreg would be useful. Agreed on both counts. The main advantage of having ctypes in the core would be to bypass these "but we can't do a Windows version without writing a C wrapper round some API calls" issues. I prefer the idea of including ctypes in the core and writing popen5 (or whatever it gets called) using it, over writing a support extension which just wraps "some" API calls. There's no way of making such an extension self-consistent in the way that _winreg is. The mix of APIs needed for popen5 is too varied. If popen5 is going to have a C extension behind it, I'd say that extension should expose higher level functions coded specifically for popen5, and be named something like _popen5.pyd. Don't try to make it generic - it won't be. But these are implementation and packaging issues. Let's get the design right first (and prototype using whatever seems convenient). Paul. -- This signature intentionally left blank
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