[bind10-dev] single vs multi module for libdns++ python binding

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2010 08:57 PM, JINMEI Tatuya / 神明達哉 wrote:
> When I wrote python binding for a new class of libdns++, this question
> arose: "why do we use a single giant python module (currently named
> 'libdns_python')"?
> 
> For comparison, dnspython uses multiple (sub)modules for "message",
> "name", "rrset", etc.  And, I felt it might be more convenient if we
> want to define module specific functions (which are not class
> methods).  It may also help separate the binding C++ source files per
> functionality (= python "module").  On the other hand, if we want to
> keep 1-to-1 relationship between C++ namespaces and python modules, I
> see it makes sense to use the single, flat module (although I'm not
> sure if there's a pragmatic benefit by having this relationship).
> 
> Is there any specific design decision on this point, or is this
> something worth discussing?
> 

Well, it's certainly worth discussing, so let me give the reasons I chose to
make one big module; there's no One Big Reason, just a few smaller ones; (btw i
did intend to make separate modules for other wrapped libraries, such as datasrc)

Most of these classes rely heavily on others, and within the bindings it is way
easier if we have direct access to the lowlevel type descriptions and functions,
so we can directly build objects of those types, instead of using the
python-side interface to make them (for instance getting the Name from an RRset,
the wrapper can now use the name_type PyTypeObject to build the object it
returns, whereas if these were separate modules, it would have to use the python
constructor, and that's at least two translation steps more, because we need
some serialized form to pass to the constructor, afaict).

Second reason was that we'd end up with a .so for every class (or cc file), and
it seems much more common to have one .so for the whole library (and you can
still use 'from libdns_python import Name' for instance)

Third was that it doesn't really matter from the use point of view imho, you
usually do one big import foo for the whole library anyway, and rarely import
foo.name import foo.rrset import foo.bar, especially since almost none of these
types live by themselves.

But yes, adding class methods is harder this way (though i don't think it's
impossible)

Another thing we cannot easily do now is extend the wrappers with pure python
code, but, i didn't think we'd want this, and stay as close to the cpp version
as possible.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx0zyAACgkQ4nZCKsdOncWmfwCgzYVPFoacnP6DhBKnM/HbV0VT
HFAAoJ5983PSusa/UqBGTxDMPwyV7ky2
=QuNH
-----END PGP SIGNATURE-----