RetroSearch Browse

Sat Feb 18 01:44:56 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-February/061322.html

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061322.html below:

PEP 332 revival in coordination with pep 349?]