[bind10-dev] python bindings

[Francis Dupont]

> answering some selected points...
> 
> > > >  - 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)
> 
> I'd be more interested in whether to implement the hash algorithm,
> developing an in-house library (like BIND9) or using an existing one,

=> as a lazy programmer I'd prefer the second solution...
Being more serious, to design a good hash algorithm is not an easy task
so I believe we should not reinvent the wheel.

> rather than which algorithm.  (in this sense my original question
> wasn't well described).  I guess in AFTR you chose jhash as the

=> I had the same issue: pickup a generic hash tool.

> algorithm and implemented (ported?) it as an in-house library.  I
> thought we'd avoid the in-house approach where possible.

=> I agree!

> > => can you make the default constructor (Name::Name()) available?
> > It is possible to call a constructor from python __init__ but only
> > one of them and here you have two (from text or wire).
> > (note I'll try to find a way to use factory functions but ...)
> 
> Hmm...I actually thought about whether we need to make the default
> constructor public.  The reason why I made it private in the current
> branch is because the default constructor makes an empty name (i.e., a
> name object with no labels).  If we allow applications to construct a
> name that way we need to handle such cases in other methods, making
> the code complicated.  So, I chose to keep it private at the moment
> until there's a strong reason to make it public.

=> is the python binding a strong reason? Note there is no real way
to hide things in python so the issue is intrinsically unresolvable.

> I'm not sure if this is strong enough to have a public default
> constructor.  But if we encounter another case, possibly in other part
> of the C++ version of the API, where we'd need it, I'll make that
> change.

=> note I don't need the default constructor itself in python bindings,
only an initial object. The default constructor provides one but it
looks it has a lot of drawbacks too.

Just for the fun:

Python 3.1.1 (r311:74480, Dec 11 2009, 00:09:48) 
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from b import *
>>> Name()
python3: name.cc:429: std::string isc::dns::Name::toText(bool) const: Assertion `count == 0' failed.
Abort

Thanks

Francis Dupont <fdupont at isc.org>

PS: for names Name("@") or Name(".") (which are the same!) seem good
choices for the initial object but we'll get the same issue when
a class will provide equivalent complex constructors...
Of course, I don't want Name("") which I believe you should be
protected against as it is not better than a public default constructor.