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 doerwalter, ezio.melotti, lemburg, ncoghlan, serhiy.storchaka, vstinner
Date 2013-11-16.13:37:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Such codecs can be represented (for 3.4) by simply not setting the attribute and leaving the output types unspecified. We don't need that complexity for the standard library, and the "not specified" escape hatch means complex codecs will be no worse off than they are now.

The elegance of Victor's proposal is that it doesn't lock us out of solving the more complex cases later (where the codec's output type depends on the input type) by permitting a tuple or dict mapping input types to output types for "encodes_to" and "decodes_to", while still solving all of our immediate problems.

This is especially relevant since we can't effectively represent codec input types until we have a ByteSequence ABC to cover the "bytes-like object" case, so demanding that the general case be handled immediately is the same as requesting that the feature be postponed completely to Python 3.5.
Date User Action Args
2013-11-16 13:37:29ncoghlansetrecipients: + ncoghlan, lemburg, doerwalter, vstinner, ezio.melotti, serhiy.storchaka
2013-11-16 13:37:28ncoghlansetmessageid: <>
2013-11-16 13:37:28ncoghlanlinkissue19619 messages
2013-11-16 13:37:28ncoghlancreate