
Are there any codecs that can take parameters at initialization time?
_codecs.utf_16_encode takes an additional parameter to request a certain endianness. This is not used in the codecs modules, though, since there are also functions for each endianness.
If not, how about supporting them?
I think this would be up to the individual codecs to support; I'm -0 on the changes to codecs.open.
f = codecs.open('output', 'wb', encoding='DES', # arguments to open() key = '...', mode = DES.ECB)
Would this better be spelled f = codecs.open('output', 'wb', encoding='DES-ECB', # arguments to open() key = '...') To write it your way: Where did you get the DES module from? If the user has to specifically access the DES module, anyway, how about f = DES.open('output', 'wb', key = '...', mode = DES.ECB)
For this to work, you'd need a few changes to codecs.py. Off the top of my head, I think StreamReader, StreamWriter, and StreamReaderWriter all need to grow **kwargs arguments for any additional arguments,
Why is that? Shouldn't you instead provide a StreamReader etc. subclass that just accepts the additional arguments? Users could then write writer = codecs.lookup("DES")[3] f = writer(open('output', 'wb'), key="...", mode=DES.ECB)
as do codecs.open() and codecs.lookup()
I cannot see at all why you want to pass arguments to lookup. Instead, wouldn't it be sufficient to pass them to the stream readers and codec functions returned? This also complicates caching of codecs, and probably the implementation of the codecs: how is lookup supposed to preserve the state in the tuple being returned? On arguments to open: mixing arguments that are consumed at different places (i.e. in .open, and in the reader/writer) makes me nervous. If we ever find the need for further standard arguments to codecs.open, it may break codecs that use these argument names for their own purposes. Regards, Martin
participants (1)
-
Martin v. Loewis