This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: base85 encoding
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: pitrou Nosy List: christian.heimes, flox, glasper, isoschiz, jcea, pitrou, python-dev, r.david.murray, serhiy.storchaka, sijinjoseph, vstinner
Priority: normal Keywords: easy, patch

Created on 2013-04-02 13:23 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue17618.diff isoschiz, 2013-04-07 15:53 Pure python Ascii85 implementation in base64.py
issue17618-2.diff isoschiz, 2013-04-14 00:24 Ascii85+Base85 encodings added to base64.py
issue17618-3.diff isoschiz, 2013-04-14 15:51 Ascii85+Base85 encodings added to base64.py
issue17618-4.diff isoschiz, 2013-04-17 22:39 Ascii85+Base85 encodings added to base64.py
issue17618-5.diff isoschiz, 2013-04-18 22:25 Ascii85+Base85 encodings added to base64.py
issue17618-5.diff serhiy.storchaka, 2013-04-19 20:38 Ascii85+Base85 encodings added to base64.py (regenerated for review) review
issue17618-fast.diff serhiy.storchaka, 2013-04-20 23:23 Corrected and optimized review
base85.patch pitrou, 2013-11-16 22:42 review
base85-2.patch pitrou, 2013-11-16 23:31 review
base85-3.patch pitrou, 2013-11-17 18:42 review
Messages (47)
msg185835 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-02 13:23
Base85 encoding (see e.g. http://en.wikipedia.org/wiki/Ascii85 ) allows a tighter encoding than Base64: it has a 5/4 expansion ratio, rather than 4/3.
It is used in Mercurial, git, and there's another variant that's used by Adobe in the PDF format.

It would be nice to have a Base85 implementation in either the binascii or base64 modules.

(unfortunately the Mercurial implementation is GPL'ed, although if we want to copy it we might simply ask them for a relicensing)
msg186214 - (view) Author: Sijin Joseph (sijinjoseph) Date: 2013-04-07 15:20
Is anyone working on this? I'd like to include this in a CPython sprint @MIT on 4/13.
msg186215 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-04-07 15:24
Antoine is talking to Mercurial about relicensing, and I believe at this point it is just a matter of working out the mechanical details (that is, he has an agreement-in-principal from them).
msg186216 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-07 15:29
The Mercurial authors have given their informal agreement for a relicensing. OTOH, they must still sign a contributor's agreement. The relicensing would allow us to use their pure Python implementation (in mercurial/pure/base85.py). OTOH, the C implementation (in mercurial/base85.c) is a ripoff of the git one, so we'd better rewrite our own.

My current plan would be the following:
- create a binascii.py and rename binascii.c to _binascii.c
- add Mercurial's pure Python implementation to binascii.py
- add a custom C implementation to _binascii.c
- make sure the binascii test suite tests both implementations

OTOH, if we don't get the Mercurial authors' contributor agreement, we can also re-write our own pure Python implementation.

In any case, our implementation should IMHO be compatible with Mercurial's (i.e. produce identical outputs for the same inputs).
msg186220 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-07 15:53
I wrote an implementation from scratch (based on the wikipedia article; I've not looked at any existing implementations) in pure Python in the attached diff. It includes tests.

Feel free to use it as the pure Python implementation if desired, though I won't be offended if you just end up using the Mercurial one. :-)
msg186221 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-07 15:58
(sorry for spam)

Forgot to mention, I included an optional keyword argument to support the 'btoa' shortcut for sequences of space characters as described in the Wikipedia article. However, I'm unsure if any other implementation supports this, so might not be worth including it in our implementation.

A better feature might be to support full btoa output, but the Wikipedia article doesn't have a complete enough specification, and I couldn't find (didn't really look for) one elsewhere. If no one uses it though, again. probably not worth including it.
msg186222 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-07 16:09
> Forgot to mention, I included an optional keyword argument to support
> the 'btoa' shortcut for sequences of space characters as described in
> the Wikipedia article. However, I'm unsure if any other implementation
> supports this, so might not be worth including it in our
> implementation.

In this issue I would really like to aim for Mercurial/git-like
behaviour: i.e. no special shortcuts, and no armoring ('<~' and '~>').
Also, the base85 alphabet used by Mercurial and git may be different, I
haven't checked.

(by the way, it seems "btoa" has been dead for a long time, I don't
think it's useful as a reference here)
msg186223 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-07 16:15
Ok, having now looked at mercurial's implementation... it looks like they implemented the RFC1924 version, whereas my implementation is the Ascii85 version (and I verified it against, amongst others: http://www.tools4noobs.com/online_tools/ascii85_encode/ ).

The Ascii85 version is what is used with PDF, and the default output format for the equivalent Ruby library, so seems useful to have. So I guess what might be desirable is to have both in the codebase?
msg186224 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-07 16:19
> The Ascii85 version is what is used with PDF, and the default output
> format for the equivalent Ruby library, so seems useful to have. So I
> guess what might be desirable is to have both in the codebase?

Yes, it could be useful to have both.
msg186225 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-07 16:42
Ok, I'm not even sure that Mercurial follows RFC1924! That RFC is specifically for encoding IPv6 addresses, and mandates that the calculations be performed on a 128bit integer.

The Mercurial implementation seems to follow the Ascii85 policy of taking each 4 bytes separately and doing 32bit arithmetic, but uses the lookup table from RFC1924, and is less lenient about spacing, and has no compression for sequences of zeroes.

It therefore looks like Mercurial (and I guess Git) have their own, non-standard base64 encoding. The Web at large mostly has "standard" Ascii85 encoding/decoding described. RFC1924 itself has a Python implementation on Github:

https://github.com/drkjam/netaddr/blob/rel-0.7.x/netaddr/ip/rfc1924.py

So I'm not sure what you want to do. I would suggest a standard Ascii85 encoder is definitely useful, and provides feature parity with Ruby. If we want the standard library to be able to read/write Mercurial/Git base64 encoded files, then I guess that can be added too. If we think RFC1924 is useful/used, then the implementation in the netaddr lib looks right.
msg186229 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-07 17:18
> So I'm not sure what you want to do. I would suggest a standard
> Ascii85 encoder is definitely useful, and provides feature parity with
> Ruby. If we want the standard library to be able to read/write
> Mercurial/Git base64 encoded files, then I guess that can be added
> too. If we think RFC1924 is useful/used, then the implementation in
> the netaddr lib looks right.

Agreed for both the Ascii85 encoder and the hg/git brand of base85
(which is used for "binary diffs", by the way). I don't think supporting
RFC1924 is useful, though.

(I think using "ascii85" and "base85" for those encodings, respectively,
provides a nice way to distinguish them)
msg186773 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-13 17:59
For the record, Mads and Brendan have submitted a contributor's agreement, so we can now take what we want from Mercurial's base85.py (which you can find at http://selenic.com/hg/file/4e1ae55e63ef/mercurial/pure/base85.py).
msg186781 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-13 18:25
Ok, great. I'll update the patch to include both encoding schemes.
msg186869 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-14 00:24
Updated patch that includes both my original implementation of Ascii85, as well as the Mercurial implementation of base85. A few notes/questions:

- I named the Mercurial base85 implementation functions with the "b85" prefix. For the Ascii85 ones, I used "a85". I considered overloading the same functions with a keyword argument to select which encoding, but rejected that. Thoughts?

- I made only minor modifications to the Mercurial code to use bytes throughout (to match all the other APIs in the module). I also updated the docstrings a bit. My goal was to change as little as possible to guarantee identical behaviour.

- I haven't made the changes to add a pure Python binascii module as suggested in msg186216. Although poorly named, "base64.py" already contains a number of other encodings, so this seemed the best place for these too. I'm happy to make that change as well though if you really want it as part of this issue.
msg186898 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-14 08:51
I want to see both algorithms to be similar so far as it is possible. It might be worth extract and reuse a common code. Mercurial's code looks far more optimal (for example a85encode has a quadratic complexity in result accumulating).
msg186924 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-14 15:51
I've updated the Ascii85 algorithms to remove the quadratic complexity, and use a single struct.pack/unpack. They should now be much quicker for large input strings.

It's difficult to factor out commonality with b85* because the encodings and rules differ. This is especially true for decode (where Ascii85 allows arbitrary whitespace, so it either has to be stepped through as I've implemented it, or it would have to first be sanitised with .replace() or similar, which is expensive for large inputs). For encode, the special cases supported by Ascii85 make it impossible to *just* use a lookup table, and the simplified algorithm for encoding means it isn't necessary to use one at all. I also wanted to keep the Mercurial code intact as much as possible, so it can be kept in sync in future if necessary.

My notes from the previous diff also still apply if anyone has thoughts on those.
msg186933 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-14 17:36
Hi and thanks for the patch!

> I named the Mercurial base85 implementation functions with the "b85"
> prefix. For the Ascii85 ones, I used "a85". I considered overloading
> the same functions with a keyword argument to select which encoding,
> but rejected that. Thoughts?

I agree, it's better like this.

> I haven't made the changes to add a pure Python binascii module as
> suggested in msg186216. Although poorly named, "base64.py" already contains 
> a number of other encodings, so this seemed the best place for these too.

Yes, I think it's ok. I was thinking about binascii in the context of making a C version, but we can refactor things later anyway.

Now about the patch: I haven't read it in detail, but it seems to lack tests for b85decode and b85encode. It should be easy enough to get some test values by calling Mercurial's version.
msg187162 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-17 13:58
After a more careful look of the b85encode code I say that it's implementation is not optimal. For the sake of simplicity the entire volume of data is copied several times. This can affect the processing of a large volume of data. On other hand, this dumb copying can be faster then more smart processing in a85encode. Only benchmarks will show the truth.

Using a trick with struct.unpack() has very unpleasant side effect. It might be a few speed up encoding, but creates the Struct object with the size is many times larger than the size of the processed data. Worse, this object is cached and continues to consume memory. Since the size of the data most likely will be unique, almost every call of b85encode creates a new object. This will lead to memory leaks.
msg187172 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-17 15:28
After searching a lot of other implementations of this encoding I conclude that there are at least three different variants.

1. The original btoa/atob encoding. 4 zeros are packaged as 'z', last incomplete 4 bytes are padded by zeros, an output is wrapped into several lines and decoder ignores '\n'. There are many implementations of this algorithm in different languages.

2. Adobe version. This is an extended version of (1). The last incomplete 4 bytes produces less then 5 output characters, an output is enclosed in <~ and ~>. Decoder ignores all ascii whitespaces, not only '\n'. There are many implementations of this algorithm in different languages.

3. Git and Mercurial version. This is a very simplified version of (1) with an alternative character set. Zeros are not packed, an output is not broken into several lines and decoder doesn't ignores any whitespaces. I don't know is whether this variant used besides Git and Mercurial.

Some implementations combine (1) and (2) (optionally enclose an output in <~ and ~>, optionally wrap an output into several lines, optionally pad last 4 incomplete bytes).
msg187174 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-17 15:47
> After searching a lot of other implementations of this encoding I
> conclude that there are at least three different variants.

Yes. The current proposal is to include both the Adobe version ("ascii85")
and the Mercurial/Git version ("base85"). btoa/atob seems extinct.
msg187186 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-17 18:14
> btoa/atob seems extinct.

At least half of ascii85 encoders in wild implement this variant.

I think we can provide a universal solution compatible (with some pre/postprocessing) with both variants. Enclose encoded data in <~ and ~> or not, and at which column wrap an encoded data. Padding can be easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').

As for Git/Mercurial's base85, what other applications use this encoding?
msg187187 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-17 18:21
Le mercredi 17 avril 2013 à 18:14 +0000, Serhiy Storchaka a écrit :
> I think we can provide a universal solution compatible (with some
> pre/postprocessing) with both variants. Enclose encoded data in <~ and
> ~> or not, and at which column wrap an encoded data. Padding can be
> easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').

That's ok with me. It's just more work for whoever does it :-)

> As for Git/Mercurial's base85, what other applications use this
> encoding?

I don't know, but they use it to produce binary diffs ("diff" chunks of
binary files), so any application wanting to parse Mercurial/Git diffs
would have to recognize base85 data.

(and I also like that the Mercurial/Git variant is the simpler of all
3 :-))
msg187191 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-17 18:39
> Using a trick with struct.unpack() has very unpleasant side effect.
> It might be a few speed up encoding, but creates the Struct object
> with the size is many times larger than the size of the processed
> data. Worse, this object is cached and continues to consume memory.
> Since the size of the data most likely will be unique, almost every
> call of b85encode creates a new object. This will lead to memory
> leaks.

Can you elaborate on this? What leakage is there? I assume this is some 
implementation quirk of the struct module that I'm not aware of.

> Le mercredi 17 avril 2013 à 18:14 +0000, Serhiy Storchaka a écrit :
>> I think we can provide a universal solution compatible (with some
>> pre/postprocessing) with both variants. Enclose encoded data in <~
>> and ~> or not, and at which column wrap an encoded data. Padding
>> can be easy implemented as preprocessing (data + (-len(data)) % 4 *
>> b'\0').
>
> That's ok with me. It's just more work for whoever does it :-)

As I mentioned in one of my previous comments, I was trying very hard 
not to touch the Mercurial solution (b85(en|de)code in the latest 
patch), and just copy it wholesale. Mostly, I don't really like the way 
the solution reads (unpythonic in my eyes), but can understand that for 
this kind of thing that might be the best way.

In my solution (a85(en|de)code) I wrote it from scratch in what I felt 
was a readable way. I can quite easily extend my version to support your 
description of the btoa/atob version (i.e. no bracketing, always pad, 
always wrap output).

I'm less convinced it's sensible to merge the ascii85 implementations 
and the Mercurial b85 one. If you really want that though, I would be in 
favour of using my a85 implementation and just changing the encode inner 
function to use the lookup table.

(we can do all this independently of the function names, which I think 
Antoine and I are agreed should be separate for the different 
implementations)

>> As for Git/Mercurial's base85, what other applications use this
>> encoding?
>
> I don't know, but they use it to produce binary diffs ("diff" chunks
> of binary files), so any application wanting to parse Mercurial/Git
> diffs would have to recognize base85 data.
>
> (and I also like that the Mercurial/Git variant is the simpler of
> all 3 :-))

I actually prefer the Ascii85 one for the simplicity of the encoding 
(shift base 85 chunks of the input by 33 to get into the printable ascii 
range) rather than the clunky lookup table approach. À chacun son goût. :-)
msg187195 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-17 18:51
> Can you elaborate on this? What leakage is there? I assume this is some 
implementation quirk of the struct module that I'm not aware of.

issue14596.
msg187196 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-17 19:03
>> Can you elaborate on this? What leakage is there? I assume this is some
> implementation quirk of the struct module that I'm not aware of.
>
> issue14596.

Thanks for the pointer. I will rework the patch for the encoder/decoders 
to use an explicit Struct so that the inbuilt cache gets bypassed and we 
don't "leak",
msg187198 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-17 19:37
Serhiy, Martin, perhaps one of you could report the potential memory leak on the Mercurial bug tracker: http://bz.selenic.com/
msg187213 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-17 22:39
New diff. Changes from the last one:

- change in struct handling to avoid issue14596

- Addition of btoa85 and atob85 functions that do legacy 'btoa' encoding/decoding. These are just wrappers around a85(en|de)code, which now have additional keyword args to control wrapping, padding, framing, and whitespace skipping

- New tests covering all 3 variants
msg187301 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-18 22:20
Raised http://bz.selenic.com/show_bug.cgi?id=3894 against Mercurial for them to workaround issue14596.
msg187302 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-18 22:25
Attached a minor tweak over the last diff - I'd forgotten to fix the Struct handling inside the Mercurial implementation as well.

All other comments still apply to this diff.
msg187477 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-20 23:23
There are some bugs in ascii85 end base85 implementations (see in Rietveld for details). Besides, ascii85 implementation was too slow. I've prepared a patch that corrects errors and speeds up encoding and decoding.

Microbenchmarks:

./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode; data = open('python', 'rb').read(1000001)"  "encode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode; data = open('python', 'rb').read(1000001)"  "encode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode, a85decode as decode; data = encode(open('python', 'rb').read(1000001))"  "decode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode, b85decode as decode; data = encode(open('python', 'rb').read(1000001))"  "decode(data)"

           Old patch  New patch
a85encode   8.4 sec    1.13 sec
b85encode   1.35 sec   1.09 sec
a85decode   9.28 sec   3.29 sec
b85decode   3.17 sec   2.37 sec
msg187514 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-04-21 16:38
As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options. Perhaps we should get rid from 'adobe' flag in a85decode and autodetect it. And perhaps to do the same with other a85decode's options.
msg187515 - (view) Author: Martin Morrison (isoschiz) * Date: 2013-04-21 17:06
On 21 Apr 2013, at 17:38, Serhiy Storchaka <report@bugs.python.org> wrote:
> Serhiy Storchaka added the comment:
> 
> As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options. Perhaps we should get rid from 'adobe' flag in a85decode and autodetect it. And perhaps to do the same with other a85decode's options.

The problem with autodetecting is that it makes it impossible for an application to use this library to verify that something is encoded in a specific way. Explicit is better than implicit. 

Otherwise, your changes look good to me.
msg187659 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-23 17:28
> The problem with autodetecting is that it makes it impossible for an
> application to use this library to verify that something is encoded in 
> a specific way. Explicit is better than implicit. 

Agreed. Also, you generally known what format your data is in. Otherwise, how do you know that it is base85 rather than, say, base64 or uuencode?
msg196006 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-08-23 19:08
Serhiy, Martin, is one of you still working on this?
msg199028 - (view) Author: Jason Stokes (glasper) Date: 2013-10-06 05:03
What issues are there with the implementation as it stands? I am happy to contribute (as I need to code a base36 implementation myself, and it's basically the same work) but it looks like the existing implementation is fine, except possibly some people don't like "adobe" being implemented by default?
msg199035 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-10-06 07:11
I'm not very interesting in working on this (but analyzing and optimizing made fun to me). You Antoine as originator definitely are interested. So make decision about interface which you need and finish the work using proposed patches as a basis. I would made a review.

I'm a little doubt about appropriateness base85 codec in the base64 module ("This module provides data encoding and decoding as specified in RFC 3548."). Base85 is not standard. But I don't see better place for it. At least the description of the base64 module should be corrected.

I suggest first resolve issue16995. Perhaps it will get suggestions about base85 interface.
msg199072 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-10-06 11:56
Well, I think the following comments (Serhiy's) should be implemented:

"""As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options."""
msg203100 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-16 22:42
Updated patch with suggested API changes, + docs.
msg203106 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-16 23:31
Updated patch incorporating Serhiy's self-review from 6 months ago (grr).
msg203147 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-17 13:37
I added more comments on Rietveld.
msg203150 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-17 13:49
> I added more comments on Rietveld. 

Did you forget to publish them?
msg203155 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-17 13:59
Grr.
msg203205 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-17 18:42
Updated patch after Serhiy's comments.
msg203215 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-17 21:49
Yet one nitpick and the patch LGTM.
msg203223 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-11-17 22:54
New changeset 42366e293b7b by Antoine Pitrou in branch 'default':
Issue #17618: Add Base85 and Ascii85 encoding/decoding to the base64 module.
http://hg.python.org/cpython/rev/42366e293b7b
msg203224 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-17 22:55
Now committed, thanks for the reviews and the code!
msg212937 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-03-08 17:54
New changeset 1853679c6f71 by R David Murray in branch 'default':
whatsnew: base65 encodings. (#17618)
http://hg.python.org/cpython/rev/1853679c6f71
History
Date User Action Args
2022-04-11 14:57:43adminsetgithub: 61818
2014-03-08 17:54:16python-devsetmessages: + msg212937
2013-11-17 22:55:05pitrousetstatus: open -> closed
resolution: fixed
messages: + msg203224

stage: needs patch -> resolved
2013-11-17 22:54:18python-devsetnosy: + python-dev
messages: + msg203223
2013-11-17 21:49:54serhiy.storchakasetmessages: + msg203215
2013-11-17 18:42:13pitrousetfiles: + base85-3.patch

messages: + msg203205
2013-11-17 13:59:43serhiy.storchakasetmessages: + msg203155
2013-11-17 13:49:23pitrousetmessages: + msg203150
2013-11-17 13:37:23serhiy.storchakasetmessages: + msg203147
2013-11-16 23:31:08pitrousetfiles: + base85-2.patch

messages: + msg203106
2013-11-16 22:42:04pitrousetfiles: + base85.patch

messages: + msg203100
2013-10-06 11:56:47pitrousetmessages: + msg199072
2013-10-06 07:12:22serhiy.storchakasetassignee: pitrou
2013-10-06 07:11:30serhiy.storchakasetmessages: + msg199035
2013-10-06 05:03:47glaspersetnosy: + glasper
messages: + msg199028
2013-09-24 21:29:25pitrousetnosy: + vstinner
2013-08-23 19:08:10pitrousetmessages: + msg196006
2013-04-23 17:28:48pitrousetmessages: + msg187659
2013-04-21 17:06:42isoschizsetmessages: + msg187515
2013-04-21 16:38:47serhiy.storchakasetmessages: + msg187514
2013-04-20 23:23:41serhiy.storchakasetfiles: + issue17618-fast.diff

messages: + msg187477
2013-04-19 20:38:24serhiy.storchakasetfiles: + issue17618-5.diff
2013-04-18 22:25:56isoschizsetfiles: + issue17618-5.diff

messages: + msg187302
2013-04-18 22:20:02isoschizsetmessages: + msg187301
2013-04-17 22:39:25isoschizsetfiles: + issue17618-4.diff

messages: + msg187213
2013-04-17 19:37:57pitrousetmessages: + msg187198
2013-04-17 19:03:35isoschizsetmessages: + msg187196
2013-04-17 18:51:07serhiy.storchakasetmessages: + msg187195
2013-04-17 18:39:40isoschizsetmessages: + msg187191
2013-04-17 18:21:48pitrousetmessages: + msg187187
2013-04-17 18:14:42serhiy.storchakasetmessages: + msg187186
2013-04-17 15:47:55pitrousetmessages: + msg187174
2013-04-17 15:28:33serhiy.storchakasetmessages: + msg187172
2013-04-17 13:58:49serhiy.storchakasetmessages: + msg187162
2013-04-14 17:36:26pitrousetmessages: + msg186933
2013-04-14 15:51:49isoschizsetfiles: + issue17618-3.diff

messages: + msg186924
2013-04-14 08:51:55serhiy.storchakasetmessages: + msg186898
2013-04-14 00:24:54isoschizsetfiles: + issue17618-2.diff

messages: + msg186869
2013-04-13 18:25:06isoschizsetmessages: + msg186781
2013-04-13 17:59:15pitrousetmessages: + msg186773
2013-04-07 17:18:29pitrousetmessages: + msg186229
2013-04-07 16:42:54isoschizsetmessages: + msg186225
2013-04-07 16:21:25serhiy.storchakasetnosy: + serhiy.storchaka
2013-04-07 16:19:23pitrousetmessages: + msg186224
2013-04-07 16:15:44isoschizsetmessages: + msg186223
2013-04-07 16:09:22pitrousetmessages: + msg186222
2013-04-07 15:58:17isoschizsetmessages: + msg186221
2013-04-07 15:53:37isoschizsetfiles: + issue17618.diff

nosy: + isoschiz
messages: + msg186220

keywords: + patch
2013-04-07 15:29:50pitrousetmessages: + msg186216
stage: needs patch
2013-04-07 15:24:24r.david.murraysetnosy: + r.david.murray
messages: + msg186215
2013-04-07 15:20:16sijinjosephsetnosy: + sijinjoseph
messages: + msg186214
2013-04-03 01:43:31jceasetkeywords: + easy
2013-04-03 01:42:50jceasetnosy: + jcea
2013-04-02 14:16:31floxsetnosy: + flox
2013-04-02 13:23:35pitroucreate