> 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? Code-bloat police anyone? --Guido van Rossum (home page: http://www.python.org/~guido/)
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