[Email-SIG] email.header.decode_header eats my spaces
barry at python.org
Thu Mar 29 06:56:19 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Mar 28, 2007, at 10:58 PM, Stephen J. Turnbull wrote:
> If you want "unicode(h)" ==> "helloworld", you need to encode the
> whole string. (Giving 'hello' the charset 'utf-8' would be a hackish
> way of doing this.)
>>> decode_header('=?us-ascii?q?hello?= =?us-ascii?q?world?=')
>> The problem in email.header module is it can not distiguish between
>> the structured and unstructured (text only) headers.
> Yikes! I didn't think of it that way before, but now that you mention
> it, my spine is freezing.
>> The Header class may have a member function like 'add_comment',
> IMHO, the Header class should be abstract, and there should be
> subclasses that handle dates, lists of addresses, lists of
> message-ids, etc. as appropriate to header fields structured in each
> particular way. Only those object handlers appropriate to a given
> field would be exposed. StarTextHeader would the unstructured
> derivative of the (implicitly structured) Header class.
I'm not sure inheritance is the right way to organize this. I think
instead you might want an interface that allows you to specify header
body 'interpreters' which can be associated with Header instances.
These interpreters would handle things like splitting and folding
header bodies, handling appending of words, etc.
Or, maybe inheritance is right. In any case, I think you also want
to also have a registry of some sort so that something like the
Parser could find a header subclass or header interpreter to use as
it was parsing a message text. You want this so an application could
[Steve says lots of other intelligent things that Barry agrees with]
I'm pretty tired right now so the only thing I can add is...
> And the email package needs to be free to deal with structured headers
> appropriately (for example, breaking very long addresses to try to
> keep line-length to a reasonable level). It may not be feasible to
> respect user preferences in all cases.
...that I want to keep in mind that because of x-headers, we have to
have an extensible architecture.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Email-SIG