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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com