Éric Araujo <[email protected]> added the comment:
> transform() and untransform() methods were also removed, I don't remember
> why/how exactly,
I don’t remember either; maybe it was too late in the release process, or we
lacked enough consensus.
> So we have rot13 & friends in Python 3.2 and 3.3, but they cannot be used
> with the regular
> str.encode('rot13'), you have to write (for example):
> codecs.getdecoder('rot_13')
Ah, great, I thought they were not available at all!
> The major issue with {bytes,str}.(un)transform() is that we have only one
> registry for all
> codecs, and the registry was changed in Python 3 [...] To implement
> str.transform(), we need
> another register. Marc-Andre suggested (msg96374) to add tags to codecs
I’m confused: does the tags idea replace the idea of adding another registry?
> I'm still opposed to str->str (rot13) and bytes->bytes (hex, gzip, ...)
> operations using the
> codecs API. Developers have to use the right module.
Well, here I disagree with you and agree with MAL: str.encode and bytes.decode
are strict, but the codec API in general is not restricted to str→bytes and
bytes→str directions. Using the zlib or base64 modules vs. the codecs is a
matter of style; sometimes you think it looks hacky, sometimes you think it’s
very handy. And rot13 only exists as a codec!
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue7475>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
