[Python-Dev] Adding .decode() method to Unicode
Wed, 13 Jun 2001 09:17:14 +0200
Paul Prescod wrote:
> 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
With the kind of attitude towards the proposed extensions which
I am currently getting in this forum, I'd rather spend my time
on something more useful.
> 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:
> MAL is basically exending it to include names from this list:
> and others.
Since these codecs live in the encoding package, I don't think we
have a namespace problem here. Codecs which are hooked into the
codec registry by the encoding package's search function will
have to provide a getregentry() entry point. If this API is not
available, the codec won't load.
Since the encoding package's search function is using standard
Python imports for loading the codecs, we can also benefit
from a nice side-effect: codec names can use Python's dotted
names (which then map to standard Python packages). This allows
codec writers like Tamito to place their codecs into Python
package thereby avoiding any conflict with other authors of
codecs with similar names.
> > 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.
(Hey, the first time *we* agree on something ;-)
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/