Synopsis:
 

import pyRegistry

basereg = pyRegistry.open('HKLM\Software\MySubKey')

reg = basereg.createKey('subkey')

print 'base subkeys:', basereg.getKeyNames()
print 'subkey subkeys:', reg.getKeyNames()

reg.setValue('a string', 'foobar')
reg.setValue('an int', 1234)
reg.setValue('a long', 5678L)
reg.setValue('a list', ['foo', 'bar', 'baz'])
reg.setValue('an empty list', [])
reg.setValue('a tuple', ('big', 'bear', 'runs'))
reg.setValue('an empty tuple', ())
reg.setValue('a unicode string', u'abcde')
reg.setValue('none', None)

for i in reg.getValueNames() :
    print i, repr(reg.getValue(i))

for i in reg.getValueNames() :
    reg.deleteValue(i)

reg.close()
basereg.deleteKey('subkey')

open(reg_path) ==> registry object

class registry :
    getValue(name) ==> value
    setValue(name, value) ==> None
    getValueNames() ==> ('name1', 'name2', ...)
    deleteValue(name) ==> None
    getKeyNames() ==> ('subkey1', ...)
    open(subkey_name) ==> registry object
    close() ==> None
    deleteKey(subkey_name) ==> None
    createKey(subkey_name) ==> registry object

open(reg_path)

Parameters:
     reg_path -- string

Returns:
    registry object

Raises:
    ValueError -- if first component of path isn't valid
    OSError -- for any error returned by Windows

Opens the registry key from the provided path. The first path component must be one of:

HKEY_LOCAL_MACHINE, HKLM,
HKEY_CURRENT_USER, HKCU,
HKEY_CLASSES_ROOT, HKCR,
HKEY_USERS, HKU,
HKEY_CURRENT_CONFIG, HKCC,
HKEY_PERFORMANCE_DATA, HKPD

If all is well a registry object is returned.

registry.getValue(name)

Parameters:
    name -- string

Returns:
    value with type dependent on underlying data

Raises:
    MemoryError
    NotImplementedError -- if underlying registry data type isn't handled
    OSError

getValue() will retrieve the requested value. The type of the returned data depends on the type of the underlying registry data. The types are mapped as follow:

    REG_NONE ==> None
    REG_DWORD ==> int
    REG_SZ, REG_EXPAND_SZ, REG_BINARY ==> string
    REG_MULTI_SZ ==> tuple of strings

Other types are not supported at this time. HKEY_PERFORMANCE_DATA is supported and is always returned as a string. Please see the registry.setValue() documentation for special notes about how empty REG_MULTI_SZ values are handled.

registry.setValue(name, value)

Parameters:
    name -- string
    value -- string | int | long | list of strings | tuple of strings | unicode string | None

Raises:
    TypeError
    OSError

setValue() sets the specified value under the key. The type of data stored in the registry is mapped as follows:

    None ==> REG_NONE
    int, long ==> REG_DWORD
    list/tuple of strings ==> REG_MULTI_SZ
    string, unicode string ==> REG_SZ

The M$ docs say that a REG_MULTI_SZ is returned as null-terminated strings ended with an exra null. This has some interesting implications. First, if you send in a list/tuple which has a string that has a null in it, you'll be suprised when you get it back because the null has to be interpreted as the end of a string. Also, we have to decide what to do if a REG_MULTI_SZ comes back from the registry as just two nulls. Does that mean we return a tuple with with a single empty string in it or a 0-length tuple? I've decided that it will mean a 0-length tuple. This means that if you pass setValue
a list/tuple with a single empty string in it when you later read it you'll instead get back an empty tuple. I wish there were a more elegant solution. If you think of one please email me. Also note that a long gets mapped into a DWORD, which of course isn't capable of holding a arbitrary size integer. Also, when you getValue() it it's going to come back as an int. Lastly, note that all strings in the registry are Unicode, but I figured most people would be happy with regular strings so although you can setValue() and unicode string to the registry it will come back from getValue() as a string.

registry.getValueNames()

Returns:
    tuple of strings

Raises:
    OSError

getValueNames() returns the names of the values in the key.

registry.deleteValue(name)

Parameters:
    name -- string

Returns:
    None

Raises:
    OSError

deleteValue() deletes the specified value from the key.

registry.getKeyNames()

Returns:
    tuple of strings

Raises:
    OSError

getKeyNames() returns the names of the keys immediately under the key.

registry.open(subkey_name)

Parameters:
     subkey_name -- string

Returns:
    registry object

Raises:
    OSError

open() opens the specified key under the key and returns a registry object for it. RegOpenKeyEx is used so this subkey must exist or an error is raised.

registry.close()

Returns:
    None

close() closes the key. close() doesn't have to be called, the key will be closed properly if/when the object goes out of scope and is garbage collected.

registry.deleteKey(name)

Parameters:
    name -- string

Returns:
    None

Raises:
    OSError

deleteKey() deletes the specified key immediately under they key. Note that in Windows95/98 this will delete the key and any contents whereas in WindowsNT the key must already be empty to be deleted.

registry.createKey(name)

Parameters:
    name -- string

Returns:
    registry object

Raises:
    OSError

createKey() creates a key under the named key and returns a new registry object for this key. This key is is created with KEY_ALL_ACCESS permissions. We discard the creation disposition indicating whether or not the key was created or an existing key was opened.

Issues:

• more elegant solution to the MULTI_SZ empty string problem
• unicode strings are always read back as ascii. Inside the registry the strings
• are all unicode. I don't think most people want all registry interaction to be with unicode strings though so I just make them ascii.
• setValue() can't take tuples/lists of unicode strings, just ascii
• perhaps make deleteKey work recursively on all platforms by doing it myself
• perhaps provide a way to allow users to specify what the target registry data type should be (e.g. pass a string have have it saved as REG_BINARY)