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 | mgiuca |
|---|---|
| Recipients | mgiuca, pitrou, pje |
| Date | 2008年07月22日.16:12:18 |
| SpamBayes Score | 0.0020800286 |
| Marked as misclassified | No |
| Message-id | <1216743140.73.0.476717155968.issue3348@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Wow, I read the WSGI spec. That seems very strange that it says "HTTP
does not directly support Unicode, and neither does this interface."
Clearly HTTP *does* support Unicode, because it allows you to specify an
encoding.
I assume then that the ISO-8859-1 characters the WSGI functions receive
will be treated as byte values. (That's rather silly; it's just dodging
the issue of Unicode rather than supporting it).
But in any event, the PEP has spoken, so we stick with Latin-1.
With respect to the text/binary stream, I think it would be best if it's
a binary stream, and we explicitly convert those str objects (which WSGI
says must only contain Latin-1 range characters) into bytes objects
(simply treating code points as bytes; in other words calling
.encode('latin-1')) and writing them to the binary stream. (Since the
WSGI spec is so adamant we deal in bytes). |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年07月22日 16:12:21 | mgiuca | set | spambayes_score: 0.00208003 -> 0.0020800286 recipients: + mgiuca, pje, pitrou |
| 2008年07月22日 16:12:20 | mgiuca | set | spambayes_score: 0.00208003 -> 0.00208003 messageid: <1216743140.73.0.476717155968.issue3348@psf.upfronthosting.co.za> |
| 2008年07月22日 16:12:20 | mgiuca | link | issue3348 messages |
| 2008年07月22日 16:12:19 | mgiuca | create | |