[Python-Dev] Patch making the current email package (mostly) support bytes

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
 > 
 > >Right.  That's where I was going with my comment to Barry about the
 > >Received headers.  Even if email isn't going to serve clients working
 > >with wire format, it needs to deal with those headers.  But where I
 > >think the headers defined by RFC 822 should be stored as str in
 > >email6, I am leaning toward storing Received headers verbatim as bytes
 > >(including any RFC 822 folding whitespace) because of the RFC 5321
 > >requirement that they be preserved exactly.
 > 
 > I think then you'd have to have two different APIs.  It'll just be too
 > confusing and error prone to return either bytes or strs from header value
 > accessors depending on the header name.

Ah, but you wouldn't *return* those bytes with the value accessor,
you'd return str, because that's what clients expect.  And you
wouldn't store bytes with a mutator -- or store a str for that matter:
you get an error because the value is immutable.  You would initialize
it with a special initializer accepting the RFC 5321 components (and
those arguments would be str and DateTimes and stuff like that).

IOW, the implementation would share basically nothing with ordinary
Headers, but the API would seem familiar, up to specific semantics
like immutability.  (And you also wouldn't be able to delete it with
the usual interface; there would be a special API meaning "I really do
want to delete this Received header, and I do understand that deletion
is prohibited where RFC 5321 rules.")  The choice of storage medium is
purely an optimization (and to remind you that this header is actually
part of the wire protocol).

It's probably more trouble than it's worth.