Author ncoghlan
Recipients barry, belopolsky, benjamin.peterson, cben, eric.araujo, ezio.melotti, flox, georg.brandl, gregory.p.smith, isoschiz, jcea, lemburg, loewis, ncoghlan, pconnell, petri.lehtinen, r.david.murray, ssbarnea, vstinner
Date 2013-10-02.15:13:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1380726829.27.0.987306683465.issue7475@psf.upfronthosting.co.za>
In-reply-to
Content
I just wanted to note something I realised in chatting to Armin Ronacher recently: in both Python 2.x and 3.x, the encode/decode method APIs are constrained by the text model, it's just that in 2.x that model was effectively basestring<->basestring, and thus still covered every codec in the standard library. This greatly limited the use cases for the codecs.encode/decode convenience functions, which is why the fact they were undocumented went unnoticed.

In 3.x, the changed text model meant the method API become limited to the Unicode codecs, making the function based API more important.
History
Date User Action Args
2013-10-02 15:13:49ncoghlansetrecipients: + ncoghlan, lemburg, loewis, barry, georg.brandl, gregory.p.smith, jcea, cben, belopolsky, vstinner, benjamin.peterson, ezio.melotti, eric.araujo, r.david.murray, ssbarnea, flox, petri.lehtinen, pconnell, isoschiz
2013-10-02 15:13:49ncoghlansetmessageid: <1380726829.27.0.987306683465.issue7475@psf.upfronthosting.co.za>
2013-10-02 15:13:49ncoghlanlinkissue7475 messages
2013-10-02 15:13:48ncoghlancreate