Greg Ewing wrote: > > > -1 on anything except a PEP that covers *all* aspects of > > encode/decode (including things that are already implemented) > > Particularly, it should clearly explain why we need a > completely new and separate namespace mechanism for these > codec things, I don't know whether MAL will write the PEP or not but the rationale for a new namespace is trivial. The namespace exists and is maintained by the Internet Assigned Names Association. You can't work with Unicode without working with names from this list: http://www.iana.org/assignments/character-sets MAL is basically exending it to include names from this list: http://www.iana.org/assignments/transfer-encodings and others. > and provide a firm rationale for deciding > whether any proposed new form of encoding or decoding > should be placed in this namespace or the module namespace. *My* answer would be that any function that has strings (8-bit or Unicode) as both domain and range is potentially a codec. -- 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