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 lemburg
Recipients lemburg, vstinner
Date 2010-05-28.11:35:24
SpamBayes Score 0.000194867
Marked as misclassified No
Message-id <>
In-reply-to <>
STINNER Victor wrote:
> STINNER Victor <> added the comment:
>> Those two encoder functions were meant to be used by Python codec
>> implementations which want to use the readbuffer and charbuffer
>> interfaces available in Python via "s#" and "t#" to access input
>> object data.
> Ah ok.
>> They are not used by the builtin codecs, 
>> but may well be in use by 3rd party codecs.
> My quick Google search didn't found any of those. I suppose that str and bytes are enough for most people. Do you know an usecase of text or bytes stored in different types than str and bytes? (I suppose the bytearray is compatible with bytes, and so it can be used instead of bytes)

Any Python object can expose a buffer interface and the above
functions then allow accessing these interfaces from within

Think of e.g. memory mapped files, image/audio/video objects,
database BLOBs, scientific data types, numeric arrays, etc.
There are lots of such object types.

>> I'm not sure why you think those functions are not encoders.
> I consider that Python3 codecs module only encode and decode text to/from an encoding, whereas Python2 had extra unrelated codecs like "base64" or "hex" (but it was decided to remove them to cleanup the codecs module).

Those codecs will be reenabled in Python 3.2. Removing them was
a mistake. The codec machinery is not limited to only working
on Unicode and bytes. It can work on arbitrary type combinations,
depending on what a codec wants to implement.
Date User Action Args
2010-05-28 11:35:26lemburgsetrecipients: + lemburg, vstinner
2010-05-28 11:35:25lemburglinkissue8838 messages
2010-05-28 11:35:24lemburgcreate