Am Di., 9. Jan. 2024 um 13:38 Uhr schrieb David Bremner <david@tethera.net>:
>
> Michael J Gruber <michaeljgruber+grubix+git@gmail.com> writes:
>
> >>
> >> I agree the bindings documentation does not make much sense.  I suspect
> >> that the bindings should follow the underlying library and return "" if
> >> the library does.  I don't use the bindings that much, so I am curious
> >> what others think.
> >
> > I might be misunderstanding the OP,and I didn't check the RFC, but
> > isn't there a difference between a missing header and an empty header?
>
> Are you suggesting the library should change as well?

I don't know. Missing vs. empty are two different cases. It may be
that in terms of e-mail standards (RFC), a missing header is
equivalent to an empty one. Then one can argue whether an empty header
is a missing header (raise error) or a missing header is an empty
header (return None) ...
Or one may distinguish between mandatory headers and optional ones.
I'd really check the RFC.

In Python, there is a difference between a dictionary key with an
empty value and a key which is not present, of course. So, if I think
of the headers as a dictionary, I would expect to differentiate
between those cases, unless the data which the dict represents (e-mail
headers) treats them as equal by RFC.

> > If there is, this may come down to the difference between testing for
> > an empty string, None or False in dynamically typed python ...
> > But it does make sense for the bindings to return an empty string or
> > None for an empty header and LookUpError for a missing header. I have
> > not checked whether our bindings in fact do.
> >
>
> AFAICT it checks explicitely for NULL, but then throws LookupError on
> any falsy return from capi.ffi.string
>
>         ret = capi.lib.notmuch_message_get_header(self._msg_p, name)
>         if ret == capi.ffi.NULL:
>             raise errors.NullPointerError()
>         hdr = capi.ffi.string(ret)
>         if not hdr:
>             raise LookupError
>         return hdr.decode(encoding='utf-8')

That clarifies what OP observed :)
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org