"Martin v. Löwis" martin at
Mon Jul 11 00:40:41 CEST 2005

Ivan Van Laningham wrote:
> Hi All--
> As far as I can tell, after looking only at the documentation (and not
> searching peps etc.), you cannot query the codecs to give you a list of
> registered codecs, or a list of possible codecs it could retrieve for
> you if you knew enough to ask for them by name.
> Why not? 

There are several answers to that question. Which of them is true,
I don't know. In order of likelyhood:
1. When the API was designed, that functionality was forgotten.
   It was not possible to add it later on (because of 2)
2. Registration builds on the notion of lookup functions. The
   lookup function gets a codec name, and either succeeds in
   finding the codec, or raises an exception.
   Now, a lookup function, in principle, might not "know" in
   advance what codecs it supports, or the number of encoding
   it supports might not be finite. So asking such a lookup
   function for the complete list of codecs might not be

   As an example of a lookup function that doesn't know what
   encodings it supports, look at my iconv module. This module
   provides all codecs that iconv_open(3) supports, yet there
   is no standard way to query the iconv library in advance
   for a list of all supported codecs.

   As an example for a lookup function that supports an infinite
   number of codecs, consider the (theoretical) encrypt/password
   encoding, which encrypts a string with a password, and the
   password is part of the codec name. Each password defines
   a new encoding, and there is an infinite number of them.

Now, if 1) would have been considered, it might have been possible
to design the API in a way that didn't support all cases that
the current API supports. Alas, somebody must have misplaced
the time machine.


More information about the Python-list mailing list