Re: BUG: Python's Message.header fails for empty headers

[Michael J Gruber <michaeljgruber+grubix+git@gmail.com>]

Am Di., 9. Jan. 2024 um 00:09 Uhr schrieb David Bremner <david@tethera.net>:
>
> Vojtěch Káně <vojta001@vkane.cz> writes:
>
> > At first, this sounds reasonable: the subject is empty, so it is
> > effectively missing. That would indicate a bug in Lieer itself and would
> > be fixed by a try-catch block. Notmuch's source for Message.header,
> > however, states:
> >
> >>:returns: The header value, an empty string if the header is not present.
> >>:rtype: str
> >
> > This makes an impression that no error should be raised and a harmless
> > value (at least for the above-mentioned code) should be returned. Yet
> > the docs continue with
> >
> >>:raises LookupError: if the header is not present.
> >
> > completely contradicting itself.
> >
> > And so here the questions:
> > Is my confusion justified? What is the expected nm's behavior? Can we
> > fix the docs and possible the implementation?
> >
>
> 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?

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.

Also, note that *sending* via lieer (i.e. via GMail API) provides more
pitfalls. For example, message IDs are rewritten, which makes it
unusable for patch series.

Cheers,
Michael\r