This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Dmitry.Jemerov, giampaolo.rodola, ncoghlan, pitrou, r.david.murray
Date 2010-09-21.02:01:45
SpamBayes Score 2.6229667e-05
Marked as misclassified No
Message-id <1285034507.5.0.0232764635259.issue9360@psf.upfronthosting.co.za>
In-reply-to
Content
OK.  It doesn't seem all that likely that we'll be adding parameters, but you never know.  So I'm OK with file becoming keyword only.

As for the overview headers...if they aren't decoded through decode_header already, why are they unicode?  If they haven't been decoded, I'd expect them to be bytes.  Or does the standard really say that these headers, extracted from the bytes message data, will be valid utf-8?  (I realize that as things stand now with email5 you'll in fact *have* to decode them in order to process them with decode_header, but that doesn't change the fact that if they are unicode I would expect that they'd be *fully* decoded.)

But I take your point about the datatypes otherwise.  Also, when we get to email6 all headers should be turned into Header objects, and there will be a way to get a datetime out of a Date Header object.
History
Date User Action Args
2010-09-21 02:01:47r.david.murraysetrecipients: + r.david.murray, ncoghlan, pitrou, giampaolo.rodola, Dmitry.Jemerov
2010-09-21 02:01:47r.david.murraysetmessageid: <1285034507.5.0.0232764635259.issue9360@psf.upfronthosting.co.za>
2010-09-21 02:01:45r.david.murraylinkissue9360 messages
2010-09-21 02:01:45r.david.murraycreate