[Email-SIG] rfc822 parser (the elephant has landed)

[Éric Araujo]

Le 10/06/2011 20:27, R. David Murray a écrit :
> On Fri, 10 Jun 2011 19:00:32 +0200, <merwok at netwok.org> wrote:
> The problems there arise from C code calling (or, rather, not calling)
> methods on the subclass.  But in email headers act *just like* strings,
> but they have *extra* methods.  So there should be no problem.  Anything
> that doesn't know about the extra methods will treat the header just
> like a string, which is exactly what we want for backward compatibility
> reasons.

Good.

> The one place where this might bite us is in the proposed support for +=
> and -=.  I haven't tested that yet, and if it does work I'm not sure
> that there won't be obscure corners in which will turn out to be broken.

I don’t know either.

>> The second cent is about naming.  Does a Mailbox represent an email
>> address?  The confusion with mailbox.Mailbox would be a problem.
> Well, that is an issue.  I'm not entirely happy about the name, but I
> haven't thought of a better one.  The problem is that we have to deal
> both with a full 'mailbox' and the 'addr-spec' subpart, and I don't know
> of *any* other name (other than 'addr-spec') for the addr-spec part.
> (Well, 'address', but you can see the problem with using that for both
> meanings...) Perhaps it would be better to use that (or rather
> addr_spec), and use 'address' for the address-with-display-name
> ('mailbox').

Yep, +1 for using addr_spec for some format defined in the RFCs, and
address for the higher-level full address more familiar to human.

> Good point.  rfc822parser is completely distinct from 'parser', which
> probably won't get deprecated.  On the other hand, once I add RFC2047
> support to it, perhaps I should rename it rfcparser (or, at least at
> first, _rfcparser).  Or perhaps _headerparser, though it doesn't
> contain *all* of the header parsing machinery.

After reading your blog post and this email, I still can’t say whether
this parser module deals with headers only or with full messages.  If
it’s the former, definite +1 to _headerparser; if it’s the latter, then
_rfcparser or something else would be okay.

Regards