Ian Bicking wrote:
> That str.encode(unicode_encoding) implicitly decodes strings seems like
> a flaw in the unicode encodings, quite seperate from the existance of
> str.encode. I for one really like s.encode('zlib').encode('base64') --
> and if the zlib encoding raised an error when it was passed a unicode
> object (instead of implicitly encoding the string with the ascii
> encoding) that would be fine.
>
> The pipe-like nature of .encode and .decode works very nicely for
> certain transformations, applicable to both unicode and byte objects.
> Let's not throw the baby out with the bath water.
The way you use it, it's a matter of notation only: why
is
zlib(base64(s))
any worse? I think it's better: it doesn't use string literals to
denote function names.
If there is a point to this overgeneralized codec idea, it is
the streaming aspect: that you don't need to process all data
at once, but can feed data sequentially. Of course, you are
not using this in your example.
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