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 benjamin.peterson, flox, georg.brandl, lemburg, loewis, vstinner
Date 2010-05-28.14:17:51
SpamBayes Score 0.00015539379
Marked as misclassified No
Message-id <4BFFD08E.5060700@egenix.com>
In-reply-to <1275054359.5.0.498273872537.issue7475@psf.upfronthosting.co.za>
Content
STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> I agree with Martin: codecs choosed the wrong direction in Python2, and it's fixed in Python3. The codecs module is related to charsets (encodings), should encode str to bytes, and should decode bytes (or any read buffer) to str.

No, that's just not right: the codec system in Python does not
mandate the types used or accepted by the codecs.

The only change that was applied in Python3 was to make sure
that the str.encode() and bytes.decode() methods always return
the same type to assure type-safety.

Python2 does not apply that check, but instead provides a
direct interface to codecs.encode() and codecs.decode().

Please don't mix the helper methods on those objects with what
the codec system was designed for. The helper methods apply
a strategy that's more constrained than the codec system.

The addition of .transform() and .untransform() for same
type conversions was discussed in 2008, but didn't make it into 3.0
since I hadn't had time to add the methods:

http://mail.python.org/pipermail/python-3000/2008-August/014533.html
http://mail.python.org/pipermail/python-3000/2008-August/014533.html
http://mail.python.org/pipermail/python-3000/2008-August/014534.html

The removed codecs don't rely on the helper methods in any way.
They are easily usable via codecs.encode() and codecs.decode()
even without .transform() and .untransform().

Esp. the hex codec is very handy and at least in our eGenix
code base in wide-spread use. Using a single well-defined
interface to such encodings is just much more user friendly
than having to research the different APIs for each of them.
History
Date User Action Args
2010-05-28 14:17:53lemburgsetrecipients: + lemburg, loewis, georg.brandl, vstinner, benjamin.peterson, flox
2010-05-28 14:17:52lemburglinkissue7475 messages
2010-05-28 14:17:51lemburgcreate