[I18n-sig] Codecs

[Andy Robinson]

Replying to MAL slightly out of order:
 
> Note that you can easily add you own wrappers of codecs.lookup()
> which then give you an object instead of the tuple.
> 
> The extensibility argument is a problem with the current
> solution, but is there really such a great need for extra
> codec APIs ? (Please remember that all codec writers would
> have to implement these new APIs -- there more you put in
> there the more difficult and less attractive it gets...)

I'm proposing a place to put non-standard extensions.
The whole point is that these are things which are useful 
for multi-byte codecs and non-European languages, but will
certainly not exist for all codecs.  These could be exposed
as functions within the relevant codec module, but it seems
clean if codecs module provides the lookup functionality,
and the particular codec can provide new 'services' itself.

> Here are some: 
> 
> * The tuple entries have two different flavours: the first
> two are readily usable encode/decode APIs, while the last
> two point to factory functions which can be used to create
> new objects.
> 
> * Tuples are much easier to create and query at C level than
> Python objects having a certain interface.
> 
> * The tuples can easily be cached and this is what the codec
> registry currently does to enhance performance. Object lookups
> are slower than tuple entry lookups (ok, no so much an argument,
> because the conversion itself is likely to cause much more
> overhead).
> 
> * There is quite a lot of code in the dist which already uses
> the tuple value (all codecs, the codec registry, sample apps,
> etc.).
> 
> * Who's going to write the code and produce the patches ?

I did argue for this originally at least twice but got 
ignored by everyone.  Now there is some support I'll make another 
bid.  If the only issue is the work involved, then we should first 
decide if it is the right thing, then see if we can find the 
resources to write the patch.  

Anyone else got opinions?

- Andy Robinson