Message 257735 - 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	gvanrossum
Recipients	Emil Stenström, ezio.melotti, gvanrossum, martin.panter, vstinner
Date	2016-01-08.02:22:45
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1452219765.79.0.31808943056.issue26045@psf.upfronthosting.co.za>
In-reply-to

Content
Any solution that encodes Unicode in a way that works for some characters but fails for others has the same problem that Unicode had in Python 3. Unfortunately we're stuck with such a solution (Latin-1) and for backwards compatibility reasons we can't change it. If we were to deprecate it, we should warn for any data given as a Unicode string, even if it's plain ASCII (even if it's an empty string :-). But even if we don't deprecate it, we can still change the text of the error message (but not the type of the exception used) to be more clear. Can we please start drafting a suitable error message here?

Any solution that encodes Unicode in a way that works for some characters but fails for others has the same problem that Unicode had in Python 3. Unfortunately we're stuck with such a solution (Latin-1) and for backwards compatibility reasons we can't change it. If we were to deprecate it, we should warn for *any* data given as a Unicode string, even if it's plain ASCII (even if it's an empty string :-).

But even if we don't deprecate it, we can still change the text of the error message (but not the type of the exception used) to be more clear.

Can we please start drafting a suitable error message here?

History
Date	User	Action	Args
2016-01-08 02:22:45	gvanrossum	set	recipients: + gvanrossum, vstinner, ezio.melotti, martin.panter, Emil Stenström
2016-01-08 02:22:45	gvanrossum	set	messageid: <1452219765.79.0.31808943056.issue26045@psf.upfronthosting.co.za>
2016-01-08 02:22:45	gvanrossum	link	issue26045 messages
2016-01-08 02:22:45	gvanrossum	create