Message227575
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. |
|
Date |
User |
Action |
Args |
2014-09-25 20:43:09 | rbcollins | set | recipients:
+ rbcollins, lemburg, pje, ncoghlan, pitrou, vstinner, benjamin.peterson, ezio.melotti, grahamd, serhiy.storchaka |
2014-09-25 20:43:09 | rbcollins | set | messageid: <1411677789.51.0.249073235395.issue22264@psf.upfronthosting.co.za> |
2014-09-25 20:43:09 | rbcollins | link | issue22264 messages |
2014-09-25 20:43:09 | rbcollins | create | |
|