Nick Coghlan added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19543> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
