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 ncoghlan
Recipients lemburg, martin.panter, ncoghlan
Date 2013-11-10.14:23:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Martin: you're right, it wouldn't be feasible to check for the 8-bit str encoding case, since the types of string literals will implicitly change between the two versions. However, the latter three cases would be feasible to check (the unicode.decode one is particularly pernicious, since it's the culprit that can lead to UnicodeEncodeErrors on a decoding operation as Python implicitly tries to encode a Unicode string as ASCII).

MAL: The latter two Py3k warnings would be in the same place as the corresponding output type errors in Python 3 (i.e. all in unicodeobject.c), so they would never trigger for the general codecs machinery.

Python 2 actually already has output type checks in the same place as the proposed warnings, it just only checks for "basestring" rather than anything more specific. Those two warnings would just involve adding the more restrictive Py3k-style check when -3 was enabled.

A Py3k warning for unicode.decode is just a straight "this method won't be there any more in Python 3" warning, since there's no way for the conversion from Python 2 to Python 3 to implicitly replace a Unicode string with 8-bit data the way string literals switch from 8-bit data to Unicode text.
Date User Action Args
2013-11-10 14:23:30ncoghlansetrecipients: + ncoghlan, lemburg, martin.panter
2013-11-10 14:23:29ncoghlansetmessageid: <>
2013-11-10 14:23:29ncoghlanlinkissue19543 messages
2013-11-10 14:23:29ncoghlancreate