"Martin v. Löwis"
martin at v.loewis.de
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