Martin v. Löwis wrote:
> 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.
Maybe it isn't worse, but the real alternative is:
import zlib
import base64
base64.b64encode(zlib.compress(s))
Encodings cover up eclectic interfaces, where those interfaces fit a
basic pattern -- data in, data out.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
