guido wrote:
> Paul, I think that the best thing to do now is to withdraw winreg.py,
> and to keep (and document!) the _winreg extension with the
> understanding that it's a wrapper around poorly designed API but at
> least it's very close to the C API. The leading underscore should be
> a hint that this is not a module for every day use.
how about letting _winreg export all functions with their
win32 names, and adding a winreg.py which looks some-
thing like this:
from _winreg import *
class Key:
....
HKEY_CLASSES_ROOT =3D Key(...)
...
where the Key class addresses the 80% level: open
keys and read NONE/SZ/EXPAND_SZ/DWORD values
(through a slightly extended dictionary API).
in 2.0, add support to create keys and write values of
the same types, and you end up supporting the needs
of 99% of all applications.
> Hopefully someday someone will eventually create a set of higher level
> bindings modeled after the Java, VB or C# version of the API.
how about Tcl? I'm pretty sure their API (which is very
simple, iirc) addresses the 99% level...
</F>
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