Message227575
| 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. |
|