Author eric.araujo
Recipients belopolsky, benjamin.peterson, cben, eric.araujo, flox, georg.brandl, gvanrossum, lemburg, loewis, ssbarnea, vstinner
Date 2011-10-17.13:38:20
SpamBayes Score 3.54267e-07
Marked as misclassified No
Message-id <1318858700.94.0.328838838557.issue7475@psf.upfronthosting.co.za>
In-reply-to
Content
> 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!
History
Date User Action Args
2011-10-17 13:38:21eric.araujosetrecipients: + eric.araujo, lemburg, gvanrossum, loewis, georg.brandl, cben, belopolsky, vstinner, benjamin.peterson, ssbarnea, flox
2011-10-17 13:38:20eric.araujosetmessageid: <1318858700.94.0.328838838557.issue7475@psf.upfronthosting.co.za>
2011-10-17 13:38:20eric.araujolinkissue7475 messages
2011-10-17 13:38:20eric.araujocreate