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, skip.montanaro
Date 2009-12-11.09:46:54
SpamBayes Score 1.5749901e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
Martin v. Löwis wrote:
> Martin v. Löwis <> added the comment:
> It's not possible to add these codecs back. Bytes objects (correctly)
> don't have an encode method, and string objects (correctly) don't have a
> decode method. The codec architecture of Python 3.x just doesn't support
> this kind of application; the codec architecture of 2.x was flawed.

Of course it does support these kinds of codecs. The codec
architecture hasn't changed between 2.x and 3.x, just the way
a few methods work.

All we agreed to is that unicode.encode() will only return bytes,
while bytes.decode() will only return unicode. So the methods won't
support same type conversions, because Guido didn't want to
have methods that return different types based on the chosen
parameter (the codec name in this case).

However, you can still use codecs.encode() and codecs.decode()
to work with codecs that return different combinations of
types. I explicitly added that support back to 3.0.

You can't argue that just because two methods don't support
a certain type combination, the whole architecture doesn't
support this anymore.

Also note that codecs allow a much more far-reaching use
than just through the unicode and bytes methods: you can
use them as seamless wrappers for streams, subclass from
them, use their methods directly, etc. etc.

So your argument that just because the two methods don't
support these codecs anymore is just not good enough
to warrant their removal.
Date User Action Args
2009-12-11 09:46:56lemburgsetrecipients: + lemburg, loewis, skip.montanaro, georg.brandl, benjamin.peterson, flox
2009-12-11 09:46:55lemburglinkissue7475 messages
2009-12-11 09:46:54lemburgcreate