David Bremner <david@tethera.net> writes: > Floris Bruynooghe <flub@devork.be> writes: > >> >> Lastly there are some downsides to the choices I made: >> - I ended up going squarely for CPython 3.6+. Choosing Python >> 3 allowed better API design, e.g. with keyword-only parameters >> etc. Choosing CPython 3.4+ restricts the madness that can >> happen with __del__ and gives some newer (tho now unused) >> features in weakref.finalizer. >> - This is no longer drop-in compatible. >> - I haven't got to a stage where my initial goal of speed has >> been proven yet. > > I guess you'll have to convince the maintainers / users of alot and afew > that this makes sense before we go much further. I'd point out that > Debian stable is only at python 3.5, so that makes me a bit wary of this > (being able to run the test suite on debian stable and similar aged > distros useful for me, and I suspect other developers). > > I know there are issues with memory management in the current bindings, > so that may be a strong reason to push to python 3.6; it seems to need > more investigation at the moment. So on earlier Python versions, sure this is possible at not too much cost. - Python 3.4+ would just cost the use of some f-strings. Not major, was just nice to use. - Python <3.4 afaik would only need a tweak to the Database.tags and Message.tags properties. I *think* swapping the caching of these using a weakref should suffice and not break the brittle Python-libnotmuch memory management. Mind you I think Python 3.0-3.3 are pretty old and not much point in supporting them. But this would also apply for 2.7 support. - Python 2.7 is probably the worst, in that keyword-only arguments would be gone. If python 2.7 is required I'd be much keener to have another go at a drop-in replacement with the memory safety features and then build the "notdb" API on top off it. But for that to be worth it people need to be convinced enough that maintaining a CFFI version is nicer than a ctypes version I guess. Kind regards, Floris _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch