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 rbcollins
Recipients benjamin.peterson, ezio.melotti, grahamd, lemburg, ncoghlan, pitrou, pje, rbcollins, serhiy.storchaka, vstinner
Date 2014-09-25.20:43:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1411677789.51.0.249073235395.issue22264@psf.upfronthosting.co.za>
In-reply-to
Content
So I guess the API concern I have is that there are two cases:
 - common spec compliant - US-ASCII + RFC2047
 - dealing with exceptions - UTF8 or otherwise

The former totally makes sense as a codec, though the current email implementation of it isn't quite a codec.

The latter almost wants to be a separate API, which I may propose as part of WSGI for HTTP/2; nevertheless in PEP-3333 its integral to the main API because of the bytes-encoded-as-codepoints-00-ff solution.

So, perhaps:
 - a codec or something looking like it that covers the common case
   this would not permit specifying codecs on decode, for instance [since RFC2047 is self describing].
 - documentation for the uncommon case. *Possibly* a helper function.
History
Date User Action Args
2014-09-25 20:43:09rbcollinssetrecipients: + rbcollins, lemburg, pje, ncoghlan, pitrou, vstinner, benjamin.peterson, ezio.melotti, grahamd, serhiy.storchaka
2014-09-25 20:43:09rbcollinssetmessageid: <1411677789.51.0.249073235395.issue22264@psf.upfronthosting.co.za>
2014-09-25 20:43:09rbcollinslinkissue22264 messages
2014-09-25 20:43:09rbcollinscreate