Fredrik Lundh wrote: > >... > > uhuh? and how exactly is this cooler than being able to do > something like the following: > > import quopri, base64 >... > > (going through the codec registry is slower, and imports more > modules, but what's so cool with that?) One argument in favor is that the base64 and quopri modules are not standardized today. In fact, Python has a huge problem with standardization of access paradigms in the standard library. We get the best standardization (i.e. of the "file interface") when we force module authors to conform to a standard in order to get some "extra feature" of the standard library. A counter argument is that the conflation of the concept of Unicode encoding/decoding and other forms of encoding/decoding could be confusing. MAL would not have to keep pointing out that "codecs are for more than Unicode encoding/decoding" if it was obvious. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
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