[Python-Dev] why doesn't print pass unicode strings on to the file object?

[M.-A. Lemburg]

Martin von Loewis wrote:
> 
> > That won't be possible without breaking user code since
> > it is well documented that codecs.lookup() returns a tuple.
> 
> Suppose codecs.lookup would return an instance of
> 
> _fields = {'encode':0,'decode':1,'reader':2,'writer':3}
> class CodecInfo(tuple):
>     __dynamic__ = 0
>     def __getattr__(self, name):
>         try:
>             return self[_fields[name]]
>         except KeyError:
>             raise AttributeError, name
> 
> What user code exactly would break? Would that be a serious problem?

All code which assumes a tuple as return value. It's hard to
say how much code makes such an assumption. Most Python
code probably only uses the sequence interface, but the C interface
was deliberately designed to return tuples so that C programmers
can easily access the data.
 
> > BTW, I don't think that adding a class CodecInfo which takes
> > the encoding name as constructor argument would introduce
> > much inflation of functions here. You will have to provide
> > such a class anyway to achieve what you are looking for, so
> > I guess this is the way to go.
> 
> I guess not. If the codec.lookup return value is changed, then I can
> write
> 
> encoder = codecs.lookup("latin-1").encode
> 
> Without that, I have to write
> 
> encoder = codecs.CodecInfo(codecs.lookup("latin-1")).encode
> 
> This is overly complicated.

No... codecs.CodecInfo("latin-1").encode

The __init__ contructor can to the call to lookup() and
apply the needed initialization of the attributes.
 
> > > It may be that an inherited tuple class might achieve the same
> > > effect. Can you identify the places where codecs.lookup is assumed to
> > > return tuples?
> >
> > I'd rather not make the interface more complicated. The C side
> > certainly cannot be changed for the reasons given above and
> > Python uses could choose your new CodecInfo class to get access
> > to a nicer interface.
> 
> What code exactly would have to change if I wanted lookup to return a
> CodecInfo object?

I don't see a need to argue over this. It's no use putting
a lot of work into inventing some overly complex (subclassing
types, etc.) strategy to maintain backwards compatibility
when an easy solution is so close at hand.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/