Martin von Loewis wrote:
>
> > > I wish codecs.lookup returned a record with named fields, instead of a
> > > list, so I could write
> > >
> > > sys.stdout = codecs.lookup("iso-8859-1").writer(sys.stdout)
> > >
> > > (the other field names would be encode,decode, and reader).
> >
> > Why don't you write a small helper function for the codecs.py
> > module ?!
>
> Because I'd like to avoid an inflation of functions. Instead, I'd
> prefer codecs.lookup to return an object that has the needed fields,
> but behaves like a tuple for backwards compatibility.
That won't be possible without breaking user code since
it is well documented that codecs.lookup() returns a tuple.
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.
> > Note that the tuple interface was chosen for sake of speed and
> > better handling at C level (tuples can be cached and are easily
> > parseable in C).
>
> 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.
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4