On Tue 2017-11-28 23:46:11 +0100, Ruben Pollan wrote:
> Message.get_property (prop) returns a string with the value of the property
> and
> Message.get_properties (prop, exact=False) returns a list [(key, value)]
This looks like a sensible approach to me. I'd be curious to hear what
others think
Floris Bruynooghe 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 _
Quoting Daniel Kahn Gillmor (2017-11-17 10:03:09)
> On Wed 2017-11-15 23:29:54 +0100, Ruben Pollan wrote:
> > Message.get_property (prop) returns a string with the value of the property.
>
> Upon review, this is actually insufficient for making robust use of the
> session-key series :(
>
> In par
Message.get_property (prop) returns a string with the value of the property and
Message.get_properties (prop, exact=False) returns a list [(key, value)]
---
bindings/python/notmuch/globals.py | 5 +++
bindings/python/notmuch/message.py | 78 +-
2 files changed,
From: Floris Bruynooghe
This introduces the beginnings of new CFFI-based Python bindings.
The bindings aim at:
- Better performance on pypy
- Easier to use Python-C interface
- More "pythonic"
- The API should not allow invalid operations
- Use native object protocol where possible
- Memory s
Hi all,
Here are the beginnings off CFFI-based Python bindings, rather
than the ctypes-based ones currently available. I started this
work in order to get faster bindings on pypy since a script of
mine was running slower on pypy than CPython. Initially aiming
for a drop-in replacement of the exi
RĂ³man Joost writes:
> Checking other bindings it seems there is an explicit check for NULL and
> we're wondering if that is really necessary. Perhaps a patch could
> initialize `*authors` in the _resolve_thread_authors_string function to an
> empty string OR at least mention it in the API docume