> 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?
> 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.
> > 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?
Regards,
Martin
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