The standard high-bit-density encoding past base-64 is base-85 (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, is an RFC somewhere, ... and maybe should find it's way into the Python standard library's codec package at some point. - Josiah On Sat, Aug 2, 2008 at 12:57 AM, Kless wrote:

It's true, I didn't pay attention to that.

So the next encoding possible would of base-128 (7-bits encoding), althought I don't know if were possible since that there would than use non-printable characters and could change the text (by use of chars. as Backspace or Delete).

On 2 ago, 03:21, Steve Holden wrote:

...

96 is approximately 2^6.585

For some reason, integral powers of two seem so much more, well, POWERFUL, if you know what I mean. Frankly I think you are being either optimistic or charitable in suggesting that such a use case might exist.

There's a reason that DEC called their equivalent of base64 "6-bit encoding".

But then I wanted to keep integer division as it was, so I am clearly a techno-luddite. If the world wants fractional bits I'm sure it's only a matter of time before some genius decides to design a 67.9-bit computer.

---

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/josiah.carlson%40gmail.com

On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. Löwis" wrote:

Josiah Carlson wrote:

...

The standard high-bit-density encoding past base-64 is base-85 (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, is an RFC somewhere,

RFC 1924, published on April 1, 1996, to shorten the representation of IPv6 addresses, so that you can write

ssh '4)+k&C#VzJ4br>0wv%Yp'

instead of having to write

ssh 1080:0:0:0:8:800:200C:417A

Most notably, section 7 (implementation issues) points out

Many current processors do not find 128 bit integer arithmetic, as required for this technique, a trivial operation. This is not considered a serious drawback in the representation, but a flaw of the processor designs.

For arbitrary-sized data, you'd have to give up 128-bit arithmetic, of course, and represent the input data to encode as a long integer.

Regards, Martin

P.S. Just in case it isn't clear: I would oppose any specific proposal to add this Ascii85 algorithm to the standard library. It would sound like we don't have any real problems to solve.

Original intent (encoding IPV6 addresses) != current usefulness (a more efficient ascii encoding of binary data). Generally, I'm of the opinion that base64 (as an ascii encoding of binary data) is sufficient for any needs I have, but there are cases where having a more efficient representation would be useful. I would also not suggest addition in the 2.6/3.0 timeframe, at best it would be 2.7/3.1, and only if someone submits a patch with testcases (note that the wiki page provides C source for one-shot encoding and decoding that doesn't require 128-bit arithmetic). Sounds to me like a project for the OP. - Josiah

On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote:

That was an April Fool's RFC.

See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has a ton of these. Great fun reading through some of them on an idle Saturday afternoon. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Oleg Broytmann schrieb:

On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote:

...

On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote:

...

That was an April Fool's RFC.

See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has a ton of these. Great fun reading through some of them on an idle Saturday afternoon. :-)

There were a lot of Python jokes for the Apr 1st. What a pity we have ceased to make such jokes.

You forget the April 1st PEPs: http://www.python.org/dev/peps/pep-0313/ http://www.python.org/dev/peps/pep-3117/ Georg

Hm, I'm sure there were many more, perhaps in different places. I recall participating with Larry Wall in the announcement of Parrot, a Python/Perl merger -- hence the name of the Perl 6 VM. And others. I'd love to see people post more references here! (Georg already posted the April Fool's PEPs.) On Sun, Aug 3, 2008 at 2:19 AM, Oleg Broytmann wrote:

On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote:

...

On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote:

...

That was an April Fool's RFC.

See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has a ton of these. Great fun reading through some of them on an idle Saturday afternoon. :-)

There were a lot of Python jokes for the Apr 1st. What a pity we have ceased to make such jokes.

http://mail.python.org/pipermail/python-list/2001-April/076593.html

http://mail.python.org/pipermail/python-list/2003-April/197232.html

http://mail.python.org/pipermail/python-list/2004-April/256320.html (Despite being a joke it really works!)

http://mail.python.org/pipermail/python-list/2005-April/315453.html

http://mail.python.org/pipermail/python-list/2005-April/315457.html

http://mail.python.org/pipermail/python-list/2006-April/375866.html

Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. _______________________________________________ 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/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Aug 3, 2008 at 10:37 AM, wrote:

Guido> Hm, I'm sure there were many more, perhaps in different places.

I figured it's a slow Sunday so I'd collect them on the wiki:

http://wiki.python.org/moin/AprilFools

Great!

I found the Python/Perl joint development press release, but only on the Wayback machine. It appears that when redesigning the python.org website that page was deemed inappropriate.

Alas, way too much stuff was dropped by the redesign. ;-( I should track down the Tim Peters award (or whatever it was called) and link that. We should probably cross-link with the Python humor page on python.org (unless that's also been axed). -- --Guido van Rossum (home page: http://www.python.org/~guido/)

>> We should probably cross-link with the Python humor page on >> python.org (unless that's also been axed). >> aahz> IIRC, the humor page was axed due to lack of updates -- I aahz> recommend finding the material using Wayback and just adding it to aahz> the wiki. It's still there: http://www.python.org/doc/humor/ it's just been absorbed into the documentation. ;-) I can't find Tim Peters' award page and don't know if you can search the Wayback Machine. (I suspect you have to know a precise URL.) Skip

Guido van Rossum wrote:

Hm, I'm sure there were many more, perhaps in different places.

Although it wasn't April 1, here's one I posted in response to python-dev discussions. http://mail.python.org/pipermail/python-list/2001-May/084169.html There was also another one concerning how to reduce the number of ways of copying a list, but Google doesn't seem to want to find it. -- Greg

On Sat, Aug 2, 2008 at 12:58 PM, Antoine Pitrou wrote:

It is also used by git for diffs of binary files, and those diffs are supposedly understood by other VCSes like Mercurial...

I'm very interested in this (for Rietveld). Where can I learn more about how git handles diffs of binary files? Does it actually show adds and deletes of sections of the file? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote:

Martin v. Löwis writes:

...

P.S. Just in case it isn't clear: I would oppose any specific proposal to add this Ascii85 algorithm to the standard library. It would sound like we don't have any real problems to solve.

According to Wikipedia, "its main modern use is in Adobe's PostScript and Portable Document Format file formats". ... git ... mercurial ... bzr

It's sort of too bad about the April Fool's RFC, because now people tend to think that an encoding with a non-power-of-2 base is just a joke. I had to overcome that when working with my programming partner, but he eventually decided that base-62 was indeed a useful encoding for our purposes. :-) I've written a few ascii encoders over the years, mostly in Python, plus an optimized C version of base-32 (with a real live Duff's Device): base62.py: http://allmydata.org/source/z-base-62/trunk-hashedformat/z-base-62/ base62/base62.py base36.py: http://allmydata.org/source/z-base-36/trunk-hashedformat/z-base-36/ base36/base36.py base32.py: http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/ base32/base32.py base32.c: http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/base32.c Regards, Zooko

Kless wrote:

So the next encoding possible would of base-128 (7-bits encoding)

A while ago I wanted to pack as much information as possible into a string of printable characters, and I came up with a base-95 encoding that packs 9 bytes into 11 characters. The application involved representing data using Python string literals, so it was important that only printable characters were used. I settled on the 9/11 combination as a reasonable compromise between packing efficiency and not having the block size too long. If anyone's interested, I could dig out the encoding and decoding routines I wrote. -- Greg