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/
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