Message 177457 - Python tracker

➜

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	claudep
Recipients	claudep, grahamd
Date	2012-12-14.10:47:21
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1355482042.3.0.601421917249.issue16679@psf.upfronthosting.co.za>
In-reply-to

Content
I may understand your reasoning when you cannot make any assumptions about the encoding of a series of bytes. I think that the case of PATH_INFO is different, because it should comply with standards, and then you can make the assumption that the original path is 'utf-8'-encoded. So either leave the string undecoded, or decode it to what the standards say. It would put un unneccessary burden on WSGI apps to always require to encode-redecode this string. Wouldn't it be possible to amend PEP 3333? Hopefully we can get some other opinions about this issue.

I may understand your reasoning when you cannot make any assumptions about the encoding of a series of bytes.

I think that the case of PATH_INFO is different, because it should comply with standards, and then you *can* make the assumption that the original path is 'utf-8'-encoded. So either leave the string undecoded, or decode it to what the standards say. It would put un unneccessary burden on WSGI apps to always require to encode-redecode this string.
Wouldn't it be possible to amend PEP 3333?

Hopefully we can get some other opinions about this issue.

History
Date	User	Action	Args
2012-12-14 10:47:22	claudep	set	recipients: + claudep, grahamd
2012-12-14 10:47:22	claudep	set	messageid: <1355482042.3.0.601421917249.issue16679@psf.upfronthosting.co.za>
2012-12-14 10:47:22	claudep	link	issue16679 messages
2012-12-14 10:47:21	claudep	create