Re: rfc822 parser (the elephant has landed)

On Jun 08, 2011, at 02:28 PM, R. David Murray wrote:

>Things have been a bit disrupted in my life over the past month (a family
>tragedy).

I'm very sorry to hear this David.  My thoughts are with you.

As always, thanks for your amazing work on email6.  You are my hero.
Comments:

* Changing the __setitem__ API.  I've always thought about this as a pure
  convenience, and that appending was the most convenient semantics.  Other
  methods, e.g. replace_header() should be included to provide the range of
  semantics that people want.  Then we'd just pick one and alias it to
  __setitem__.  I'm mixed as to whether appending still is the most convenient
  alias, since in my own code I often `del msg[header]; msg[header] = foo`.
  But that also changes the header order so it's not a perfect replacement.

* Unique headers: is this controlled or influenced by a policy?  For example,
  duplicate Subjects might be disallowed by RFC 5322, but could conceivably be
  allowed (or at least not prohibited) by other email-like protocols.

  Also, while some fields like CC allow only occurrence, it can contain
  multiple values in that single field.  Is it totally insane to say that
  `msg['cc'] = 'address'` would append `address` to the existing value?  It
  probably is, but having to do that manually also kind of sucks.

  Some headers have other constraints (RFC 5322, $3.6).  For example
  Message-ID can technically appear zero times, but "SHOULD be present".  Part
  of me thinks it should be out of scope for email6 to enforce this, and I'm
  not sure where that would get enforced anyway, but I'm just wondering if
  you've thought about that.

* Datetimes: \o/.  It will be awesome when I can `msg['date'] = a_datetime`.
  While it does seem reasonable that a naive datetime uses -0000, it should
  also be very easy for folks to add a Date header that references the local
  timezone, since I suspect that will be a more common use case than UTC.  I
  don't know what the answer for that is though.

* As for header parsing, have you looked at the pyparsing module?  I don't
  write many parsers, and have no direct experience with pyparsing, but I keep
  hearing really good things about it.  OTOH, it's not in the stdlib, so it
  would present problems if email6 were to adopt it.  Still, I don't envy this
  part of the job, and I sympathize with the rabbit-hole effect of "just one
  more little thing..." ;)  Oh, and I'm just blown away impressed by the work
  you've done on the parser.

* Are there operations on Groups and Mailboxes?  E.g. in your example, I see
  that you added `[email protected]` to the To header by string
  concatenation.  What if for example, I had a number of addresses that I
  wanted to combine into a Reply-To header (which RFC 5322 says I can only
  have one of).  Would I be able to do something like the following:

  >>> msg['reply_to'].mailboxes.append('[email protected]')

  and have the printed representation of the message look correct?  Ah, maybe
  something like your last example in the What's Missing section covers this.

* Oooh!  Your example has an `== None` which should probably be `is None` :)

Really, *really* fantastic stuff.
-Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJN7+AyAAoJEBJutWOnSwa/Bh4P/jkQrfEw3fdmDaIgR59uH+A8
GXabcmsFRWKoT8VdYon0Yx0sr6sMdWVTZjZf7qnH8JJc7VB+9lAP60IVWevaX7yh
79axSCkPtXiv9vo1ey8UGcM4p7vdSXO5YPluQiLuw6lMbGDnNAlQaXAxPJ5g5h2Z
D6ILHatRwXwKpvcPUcSz15WP8/r575lGkKwZ/LAK6s50HSs1phqDPRXhrH2vaz+g
nV3Yqjmrhs+Yx65ZwVzluXuhtNppw8wPzjAYFXvBCnz/5buz/Mu8hL/NZ2St/FLQ
BpPZvniW2RC6Z+SWNvUen9NM1dKXpApEAye1HxWyzKSHNeOLUX0J379C33nqupmo
3OmfOJgFcdcOwgdIZZgOtcakwRONwNu57BF7C58Lv8rVOjen9qdFDiqzCX7yTVH4
HvTRpuu2xAWEIO+oAOjaMBAH5jVqaOaqo+stjHOL8ogig4N5GVLenoTRb1IZjrKb
cKV8BFIyMh9fpoNu947VGVI/Yl8/2+XLwvTKkooSnsebkBoRKxk+7JfAJXy1S+an
0ulVWZqSHINuyu9peWf6tyJnpNFKR4v0j9v64JuNERbJQ95joppUqr6pUJNcrE0P
U5JQW5iYvp7YWUL4/L+s+OMljGGD752+Ixd4KC6bWiD3rBoOIb7VK++0BNUYXoD5
lD9a9mlqqnALeHGMAzbW
=r2qr
-----END PGP SIGNATURE-----