Message145693
> 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! |
|
Date |
User |
Action |
Args |
2011-10-17 13:38:21 | eric.araujo | set | recipients:
+ eric.araujo, lemburg, gvanrossum, loewis, georg.brandl, cben, belopolsky, vstinner, benjamin.peterson, ssbarnea, flox |
2011-10-17 13:38:20 | eric.araujo | set | messageid: <1318858700.94.0.328838838557.issue7475@psf.upfronthosting.co.za> |
2011-10-17 13:38:20 | eric.araujo | link | issue7475 messages |
2011-10-17 13:38:20 | eric.araujo | create | |
|