Guido van Rossum wrote:
>
> > We already have "data".encode(encoding) which encodes the string data
> > by passing it through the encoder of the given encoding.
> >
> > Wouldn't it be worthwhile to add direct access to codec decoders
> > through string methods as well ?
> >
> > (Note that this addition only makes sense for string objects,
> > since Unicode cannot be decoded.)
> >
> > Also, would there be any objections adding some more standard
> > codecs to the system ? I'm thinking of wrapping the binascii
> > module APIs in form of codecs...
>
> Can you provide examples of where this can't be done using the
> existing approach?
There is no existing elegant approach except hooking up to the
codecs directly. Adding .decode() is really a matter of adding
symmetry.
Here are some example of how these two codec methods could
be used:
xmltext = binarydata.encode('base64')
...
binarydata = xmltext.decode('base64')
zzz = data.encode('gzip')
...
data = zzz.decode('gzip')
jpegimage = gifimage.decode('gif').encode('jpeg')
mp3audio = wavaudio.decode('wav').encode('mp3')
etc.
Basically all content transfer encodings can take advantage of
these two methods.
It's not really code bloat, BTW, since the C API is there;
the .decode() method would just expose it.
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4