Hi Floris--

On Sun 2017-12-17 19:08:18 +0100, Floris Bruynooghe wrote:

> Thanks for all the feedback on an early post of my CFFI-based libnotmuch
> Python bindings.  I've now completed these somewhat more and they now
> have most of the functionality.  Here's what's new since last time:

thanks for this work!  I appreciate and share your goals of fixing the
memory management models so that notmuch objects can't incur the crashes
i've heard reported, and i also appreciate your attention to performance
concerns on different python platforms (e.g. making sure things are
performant on both CPython and PyPy).

I confess that i haven't read the series in full, but i have two main
concerns that i'd generally use to evaluate proposals like this:

 0) how much does the API change?  that is, if we're expecting existing
    users of the notmuch python bindings to adopt this new approach, how
    much pain are we putting them through?  How much of an effort has
    been made to reduce that pain, and do we have a clear and
    comprehensive porting guide?

 1) how accessible is the new implementation for contributions from
    other developers?  For example, a transition to a highly idiomatic
    style of python that no other developers would be able to improve
    would put a large maintenance burden on you.

Do you have any thoughts about these questions?

For example, for point 0, have you tried to run alot or some other
python-based notmuch MUA against this newer python binding?  what
changes were necessary?

For example, for point 1, can you show me how i would (as a fellow notmuch
contributor) create a patch to add support for some of the recent (post
0.25.3) changes to notmuch in the python interface?

Also, the old python bindings are actually directly exercised by the
notmuch test suite.  i see you've adopted the tox.ini convention to
trigger a run of pytest, but that's not how the current test suite
works.  Do you think notmuch needs to adopt tox in order to use this
series, or do you think you could integrate the testing of this module
into the currently-existing test suite?

the more things that this series changes at once, the harder it is to
push for its integration.  bite-size, piecemeal changes will have an
easier path to wider adoption.

thanks for this work!  I look forward to us solving the problems you're
working on it this series.  I hope we can get there :)


Attachment: signature.asc
Description: PGP signature

notmuch mailing list

Reply via email to