[bind10-dev] python bindings

[Francis Dupont]

I looked at python bindings for BIND 10 (the Name class from parkinglot),
I have some comments:
 - there is a dependency on *recent* versions of automake:
  old versions of automake (i.e., the version you should get on most
  distribs per default) fail to recognize python 3

 - to build a dynamic object (i.e., xxx.so) as needed for a python
  extension the code must be compiled with -fPIC. As it has a low
  impact I suggest to make this option the default for libraries.

 - a hash method is really needed (not only for python but I can't see
  a DNS tool without a hashtable with names as keys)

 - for DNSSEC we need a canonize/specialized toWire/..., at least something!

 - I have a mixed opionion about to_unicode, IMHO it is more about IDN
  support (i.e., when there will be an IDN support it will be in it)

 - for using the C++ class in dnspython, set/get methods to labels
  (a vector of labels?) is required. (Note dnspython is python 2.6,
  not python 3).

 - the parkinglot code is not complete, what code I should use?
  I need something I can easily compile (i.e., generate libdns.a)
  and where no interesting function returns an unresolved reference
  on (late) linking. It seems branches/jinmei-dnsmessageapi is
  better than parkinglot, Jinmei?

 - the bug exists for parkinglot but I am afraid it is shared:
  Name::Name("") raises a runtime error.

Regards

Francis Dupont <fdupont at isc.org>

PS: my strategy is to write an standard extension in C/C++ and
as it generates builtin types to encapsulate C++ classes in
direct python subclasses (i.e., class Name(cName): ).
I have still to port the buffer stuff (bytes <-> buffer conversion).