[getdns-api] Python bindings plans

Saúl Ibarra Corretgé saghul at gmail.com
Mon Jun 30 12:43:44 MST 2014

Hash: SHA1

Hi all,

Sorry for breaking the thread, I wasn't subscribed before this message
was sent :-/

> Hi, folks:
> I'm reworking the Python bindings with an eye towards an initial 
> release in about three weeks.  This code will be the basis for the
> mature release.  There will be a fairly fundamental reworking of
> the interfaces, but we'll be keeping the current interface
> available through one or two releases to give people a chance to
> transition.
> The two major changes are intended to make the interfaces more
> Pythonic.  They are:
> 1) the introduction of a new Context object, with queries being
> methods associated with that object (note that this is consistent
> with the design of the Node.js bindings) 2) context attributes are
> going to be treated as Python attributes, so that rather than (for
> example) using
> c = getdns.context_create() getdns.context_set_resolution_type(c, 
> you'd use
> c = getdns.Context() c.resolution_type =
> Basically, the setters and the getter are going away.  The results 
> dict is going to stay the same but over time we may be adding some
> convenience methods for access.
> While I don't love having async support in the bindings, that will
> be included as well.
> Comments and suggestions are very welcome.

Thanks for taking the time to ask the community for feedback. I'm
actually very interested in the Python getdns bindings, which I's like
to use to replace c-ares with, for the following reasons:

- - c-ares development is kind-of stalled
- - individual queries cannot be cancelled (all queries of a given
channel can, however)
- - lack of DNSSEC support

So, having written c-ares bindings for Python [0] and then used them
with several asynchronous i/o frameworks such as asyncio [1], here is
a braindump of what would be nice to have IMHO:

- - Use CFFI[2] instead of creating a C module. This is somewhat
controversial, but I think it would be a very nice thing to do now
that it's still early in the process. The Python C API is specific to
CPython, and the emulation layer in PyPy is not great, so basically
only CPython would be supported. With CFFI, both CPython and PyPy
would be supported, and IIRC there is a CFFI backend for Jython in
development, so Jython would eventually be supported.

- - Good async support. I see you don't like this one much, care to
elaborate? I think it's essential, as everyone seems to have drank the
async kool-aid these days ;-) The getdns C API provides great support
for async frameworks, I think that should be exposed in such a way
that it makes it easy to integrate with something like plain select
and asyncio. FWIW, here is how I did it for c-ares [3]. The getdns C
API looks more flexible, so python-getdns could do it nicer.

- - More "Pythonic" API. This has already been addressed with the
proposal of a Context object, which looks great! It would be nice to
see that extended to a Transaction object, foe example, which would be
returned by the async functions. The user could attach arbitrary data
to it, or call Transaction.cancel() to cancel it.

I understand writing emails is easier than actually working on the
code, I hope once the new design is released I can contribute with
code as well :-)

Keep up the good work!

Kind regards,

[0]: https://github.com/saghul/pycares
[1]: https://github.com/saghul/aiodns

- -- 
Saúl Ibarra Corretgé

Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


More information about the getdns-api mailing list