[Dazuko-devel] changes in the Python language binding

[Gerhard Sittig]

Recently the style improvement supplied by Stefan Grundmann (see
http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=3605
for details) was incorporated into the Python language binding.  I
slightly changed the patch and adopted it to the latest development.
Any errors are mine.

These changes break compatibility to the previous version.  The
changes are:
- switched to the _TS() routines so multiple instances may be used now
- switched from a procedure (C style) to an OO (Python style)
  interface:  introduced the dazuko.Dazuko class, the constructor
  automatically registers with Dazuko, the destructor releases held
  accesses and unregisters with Dazuko (if necessary)
- the registered ID as well as accesses are cleanly encapsulated, no
  more ugly passing pointers around
- the version() and ioversion() routines still are methods of the
  module, not of the class


The module's help string was updated to even stronger point out the
responsibility a Dazuko enabled application accepts for the system's
stability.

I cannot suggest relying on the automatic release of accesses or
registrations.  That's why I kept an explicit unregister() method in
place.  Waiting for the GC to collect unneeded instances may be too
late for the machine which is already hanging because of still
registered instances not requesting and handling accesses.

That the returnAccess() method's interface changed should not be a
problem because applications have to be touched anyway to switch to
the OO style use of the language binding.  Not passing an internal
reference of the C library to the Python caller is well worth the
change, especially because BadThings(TM) would happen when the
reference gets lost, damaged or changed.


You may stick with version 0.1 (C style) of the binding if already
installed or deployed with your application.  Or you may switch to the
0.2 (OO style) language binding which will be part of the 2.1 release
of Dazuko.

The OO interface can be detected by the presence of the dazuko.Dazuko
class or may be derived from the following constants.  The RCS/CVS
revision of the module is 1.3 which is held in the dazuko.VERSION
constant.  Since the name "VERSION" does not really reflect well that
it holds a CVS revision, I introduced the new constants
"MODULE_REVISION" (now 1.3 and identical to "VERSION") and
"MODULE_VERSION" (now 0.2 as defined in setup.py).  The "VERSION"
constant is kept for compatibility.


We now have a clean Python style interface for Dazuko which now looks
the way it should always have looked like from the beginning.  Have
the appropriate amount of fun ... :)


virtually yours                                     Gerhard Sittig
pgp fingerprint AF29 3CD2 A531 F5A8 5F42  CB9A 1B7F 59F8 BA7A 9EE5
-- 
Gerhard Sittig
Software Engineer

H+BEDV Datentechnik GmbH
Lindauer Strasse 21, 88069 Tettnang, Germany
tel +49 (0) 7542-500500, fax +49 (0) 7542-500576
<mailto:address@hidden> <http://www.antivir.de>