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, ncoghlan, serhiy.storchaka, vstinner
Date 2013-11-16.09:16:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The full input/output type specifications can't be implemented sensibly without also defining at least a ByteSequence ABC. While I think it's a good idea in the long run, there's no feasible way to design such a system in the time remaining before the Python 3.4 feature freeze.

However, we could do something much simpler as a blacklist API:

    def is_unicode_codec(name):
        """Returns true if this is the name of a known Unicode text encoding"""

    def set_as_non_unicode(name):
        """Indicates that the named codec is not a Unicode codec"""

And then the codecs module would just maintain a set internally of all the names explicitly flagged as non-unicode.

Such an API remains useful even if the input/output type support is added in Python 3.5 (since "codecs.is_unicode_codec(name)" is a bit simpler thing to explain than the exact type restrictions).

Alternatively, implementing just the "encodes_to" and "decodes_to" attributes would be enough for str.encode, bytes.decode and bytearray.decode to reject known bad encodings early, leaving the input type checks to the codecs for now (since it is correctly defining "encode_from" and "decode_from" for many stdlib codecs that would need the ByteSequence ABC).
Date User Action Args
2013-11-16 09:16:51ncoghlansetrecipients: + ncoghlan, lemburg, vstinner, serhiy.storchaka
2013-11-16 09:16:51ncoghlansetmessageid: <>
2013-11-16 09:16:51ncoghlanlinkissue19619 messages
2013-11-16 09:16:51ncoghlancreate