Martin v. Löwis wrote:
>>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.
>
>
> So should I write
>
> 3.1415.encode("sin")
>
> or would that be
>
> 3.1415.decode("sin")
The ambiguity shows that "sin" is clearly not an encoding. Doesn't read
right anyway.
[0.3, 0.35, ...].encode('fourier') would be sensible though. Except of
course lists don't have an encode method; but that's just a convenience
of strings and unicode because those objects are always data, where
lists are only sometimes data. If extended indefinitely, the namespace
issue is notable. But it's not going to be extended indefinitely, so
that's just a theoretical problem.
> What about
>
> "http://www.python.org".decode("URL")
you mean 'a%20b'.decode('url') == 'a b'? That's not what you meant, but
nevertheless that would be an excellent encoding ;)
--
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
