[Python-Dev] The os module, unix and win32

Dave Brueck dave at pythonapocrypha.com
Thu Jan 8 17:46:42 EST 2004

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:


(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 mailing list