[Python-Dev] The os module, unix and win32
dave at pythonapocrypha.com
Thu Jan 8 17:46:42 EST 2004
> > 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:
(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
> 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.
More information about the Python-Dev