[ANN] regobj - Pythonic object-based access to the Windows Registry
ryan at rfk.id.au
Tue May 5 00:17:38 CEST 2009
> > I've just released the results of a nice Sunday's coding, inspired by
> > one too many turns at futzing around with the _winreg module. The
> > "regobj" module brings a convenient and clean object-based API for
> > accessing the Windows Registry.
> Sounds very interesting, Ryan. Just a couple questions about the
> dictionary interface.
Thanks for you interest and suggestions, a couple of quick points below.
> I could see how you could map numbers to DWORD, 2.x str/3.x bytes to
> binary, and 2.x unicode/3.x str to REG_SZ. But you don't document such
> a translation, so it is unclear exactly what you actually do. This
> would be somewhat weird in 2.x, though, where str commonly would want to
> map to String rather than Binary.
> It seems almost necessary to add an explanation of whatever mapping is
> presently done, to have complete documentation.
I guess I just ran out of steam on the documentation front :-)
Currently it maps integers to DWORD and anything else to REG_SZ. The
idea of having a distinct Value class is to allow a more nuanced mapping
to be developed, but I haven't got down to the details of that yet - my
current application only requires REG_SZ.
> Thinking more, I wonder if it is possible to create objects of type
> Value to put in the dictionary to allow specification of multistring and
> expandablestring Registry types, but then the dictionary name would have
> to be redundant with the name attribute in the Value object. Maybe a
> nameless value type could be invented, with just type and data attributes?
It certainly is, using syntax like:
HKCU.foo.bar["key"] = Value("%SYSTEMROOT%/mydir",type=REG_EXPAND_SZ)}
Putting a nameless Value() instance in the initialisation dictionary
should also work (but as you note, there's no documentation or tests for
http://www.rfk.id.au | This message is digitally signed. Please visit
ryan at rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 204 bytes
Desc: This is a digitally signed message part
More information about the Python-list