gh-101178: Add Ascii85, Base85, and Z85 support to binascii #102753

kangtastic · 2023-03-16T11:38:01Z

Synopsis

Add Ascii85, Base85, and Z85 encoder and decoder functions implemented in C to binascii and use them to greatly improve the performance and reduce the memory usage of the existing Ascii85, Base85, and Z85 codec functions in base64.

No API or documentation changes are necessary with respect to any functions in base64, and all existing unit tests for those functions continue to pass without modification.

Resolves: gh-101178

Discussion

The base85-related functions in base64 are now wrappers for the new functions in binascii, as envisioned in the docs:

The binascii module contains a number of methods to convert between binary and various ASCII-encoded binary representations. Normally, you will not use these functions directly but use wrapper modules like uu or base64 instead. The binascii module contains low-level functions written in C for greater speed that are used by the higher-level modules.

Parting out Ascii85 from Base85 and Z85 was warranted in my testing despite the code duplication due to the various performance-murdering special cases in Ascii85.

Comments and questions are welcome.

Benchmarks

Updated December 28, 2025.

# bench_b85.py

# Note: EXTREMELY SLOW on unmodified mainline CPython
#       when tracing malloc on the base-85 functions.

import base64
import sys
import timeit
import tracemalloc

funcs = [(base64.b64encode, base64.b64decode),  # sanity check/comparison
         (base64.a85encode, base64.a85decode),
         (base64.b85encode, base64.b85decode),
         (base64.z85encode, base64.z85decode)]

def mb(n):
    return f"{n / 1024 / 1024:.3f} MB"

def stats(func, data, t, m):
    name, n, bps = func.__qualname__, len(data), len(data) / t
    print(f"{name} : {n} b in {t:.3f} s ({mb(bps)}/s) using {mb(m)}")

if __name__ == "__main__":
    data = b"a" * int(sys.argv[1]) * 1024 * 1024
    for fenc, fdec in funcs:
        tracemalloc.start()
        enc = fenc(data)
        menc = tracemalloc.get_traced_memory()[1] - len(enc)
        tracemalloc.stop()
        tenc = timeit.timeit("fenc(data)", number=1, globals=globals())
        stats(fenc, data, tenc, menc)

        tracemalloc.start()
        dec = fenc(enc)
        mdec = tracemalloc.get_traced_memory()[1] - len(dec)
        tracemalloc.stop()
        tdec = timeit.timeit("fdec(enc)", number=1, globals=globals())
        stats(fdec, enc, tdec, mdec)

# Python 3.15.0a3+ (heads/main:0efbad60e13, Dec 28 2025, 11:02:16)
# ./configure --enable-optimizations --with-lto

# Unmodified
$ time ./python bench_b85.py 64
b64encode : 67108864 b in 0.092 s (693.266 MB/s) using 42.667 MB
b64decode : 89478488 b in 0.234 s (364.961 MB/s) using 56.889 MB
a85encode : 67108864 b in 7.163 s (8.935 MB/s) using 2664.401 MB
a85decode : 83886080 b in 14.478 s (5.526 MB/s) using 3332.254 MB
b85encode : 67108864 b in 6.965 s (9.189 MB/s) using 2664.401 MB
b85decode : 83886080 b in 10.082 s (7.935 MB/s) using 3332.254 MB
z85encode : 67108864 b in 7.245 s (8.834 MB/s) using 2664.102 MB
z85decode : 83886080 b in 9.666 s (8.277 MB/s) using 3332.254 MB

real    9m44.382s
user    9m27.271s
sys     0m12.747s


# With this PR
b64encode : 67108864 b in 0.085 s (753.375 MB/s) using 42.667 MB
b64decode : 89478488 b in 0.230 s (371.282 MB/s) using 56.889 MB
a85encode : 67108864 b in 0.094 s (681.709 MB/s) using 0.000 MB
a85decode : 83886080 b in 0.191 s (418.019 MB/s) using 0.000 MB
b85encode : 67108864 b in 0.075 s (850.118 MB/s) using 0.000 MB
b85decode : 83886080 b in 0.141 s (567.490 MB/s) using 0.000 MB
z85encode : 67108864 b in 0.074 s (864.559 MB/s) using 0.000 MB
z85decode : 83886080 b in 0.173 s (462.854 MB/s) using 0.000 MB

real    0m1.865s
user    0m1.726s
sys     0m0.126s

The old pure-Python implementation is two orders of magnitude slower and uses over O(40n) temporary memory.

ghost · 2023-03-16T11:38:28Z

All commit authors signed the Contributor License Agreement.

kangtastic · 2024-03-19T08:58:57Z

It's a year later, and Z85 support has been added to base64 in the meantime. So while bringing this PR up to date with main, I added Z85 support to it as well.

For reference, this is the benchmark run that led me to do so.

# After merging main but before adding Z85 support to this PR
(cpython-b85) $ python bench_b85.py 64
b64encode : 67108864 b in 0.121 s (527.435 MB/s) using 42.667 MB
b64decode : 89478488 b in 0.309 s (276.188 MB/s) using 56.889 MB
a85encode : 67108864 b in 0.297 s (215.150 MB/s) using 0.000 MB
a85decode : 83886080 b in 0.205 s (390.751 MB/s) using 0.000 MB
b85encode : 67108864 b in 0.106 s (604.359 MB/s) using 0.000 MB
b85decode : 83886080 b in 0.204 s (393.040 MB/s) using 0.000 MB
z85encode : 67108864 b in 0.204 s (313.610 MB/s) using 80.000 MB
z85decode : 83886080 b in 0.300 s (266.670 MB/s) using 100.000 MB

The existing Z85 implementation translates from the standard base85 alphabet to Z85 after the fact and within Python, so it was already benefiting from this PR but with substantial performance and memory usage overhead. That overhead is now gone.

python-cla-bot · 2025-04-18T09:43:15Z

All commit authors signed the Contributor License Agreement.

Add Ascii85, base85, and Z85 encoders and decoders to `binascii`, replacing the existing pure Python implementations in `base64`. No API or documentation changes are necessary with respect to `base64.a85encode()`, `b85encode()`, etc., and all existing unit tests for those functions continue to pass without modification. Note that attempting to decode Ascii85 or base85 data of length 1 mod 5 (after accounting for Ascii85 quirks) now produces an error, as no encoder would emit such data. This should be the only significant externally visible difference compared to the old implementation. Resolves: pythongh-101178

kangtastic · 2025-04-21T05:18:40Z

PR has been rebased onto main at 78cfee6 with squashing.

sergey-miryanov · 2025-04-21T08:58:43Z

Note that attempting to decode Ascii85, base85, or Z85 data of length 1 mod 5 now produces an error, as no encoder would emit such data. This should be the only significant externally visible difference compared to the old implementations.

I believe you have to document this change.

kangtastic · 2025-04-21T10:27:58Z

Note that attempting to decode Ascii85, base85, or Z85 data of length 1 mod 5 now produces an error, as no encoder would emit such data. This should be the only significant externally visible difference compared to the old implementations.

I believe you have to document this change.

Fair point, I could do that.

In case anyone argues for keeping the old behavior (silently ignoring length 1 mod 5), I won't do it just yet.

Lib/base64.py

If we were strictly following PEP-0399, _base64 would be a C module for accelerated functions in base64. Due to historical reasons, those should actually go in binascii instead. We still want to preserve the existing Python code in base64. Parting out facilities for accessing the C functions into a module named _base64 shouldn't risk a naming conflict and will simplify testing.

This is done differently to PEP-0399 to minimize the number of changed lines.

As we're now keeping the existing Python base 85 functions, the C implementations should behave exactly the same, down to exception type and wording. It is also no longer an error to try to decode data of length 1 mod 5.

kangtastic · 2025-04-27T03:51:24Z

The PR has been updated to preserve the existing base 85 Python functions in base64 and modify the new base 85 C functions in binascii to closely match their behavior. Notably, trying to decode data of length 1 mod 5 is no longer an error.

Lib/_base64.py

Lib/base64.py

Lib/test/test_base64.py

Importing update_wrapper() from functools to copy attributes is expensive. Do it ourselves for only the most relevant ones.

This requires some code duplication, but oh well.

Using a decorator complicates function signature introspection.

Do we really need to test the legacy API twice?

picnixz · 2025-12-26T15:26:52Z

How about separate functions for Base85 and Z85 only on the Python API side? I'm inclined to keep them combined on the C side to avoid code duplication (with wrapper functions for the z85 parameter).

It may be better to separate them for PGO though I have no idea whether there will be an impact or not (this needs to be measured). If you're worried about parts of the code being duplicated, it can be refactored into macros (or into smaller functions). However, we should avoid the user-interface exposing different flavors with boolean switches (we usually try to avoid this, as illustrated by examples of filter/itertoolsfilterfalse and recently fnmatch.filter/fnmatch.filterfalse where the API was explicitly designed to avoid switches).

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

serhiy-storchaka · 2025-12-27T12:22:30Z

Interested to see how you did it.

I pushed these changes. The code is similar to b2a_base85(), with additional special cases. The difference is so small (10-25%) in comparison with 100x of the Python implementation, that it would not be a crime to use the same code for all three encoders (I do not suggest this, this is just an option if we want to minimize the C code).

See also #143216 -- it reuses the same code for wrapping line in b2a_base64().

How about separate functions for Base85 and Z85 only on the Python API side?

Yes, of course. b2a_base85() and b2a_z85() can use the same C code with different arguments.

kangtastic · 2025-12-27T17:47:37Z

Hi @picnixz, thanks for reviewing.

A few comments. I'd appreciate, as it's new code, that PEP-7 is followed.

I did attempt to follow PEP-7; did you have something specific in mind? If it's about the old-style variable declarations at the top of each C function, the reason for that was to match much of the rest of binascii.c as PEP-7 allows.

But since @serhiy-storchaka partially undid that in 0df9a40 (apparently following ca99af3) I don't mind cleaning up the style a bit more.

picnixz · 2025-12-27T17:58:21Z

It's mainly to avoid } else { or } else if { and avoid many statements on the same line (AFAICT, it was introduced in this PR, e.g., if (cond) then;). Surrounding consistency is more with respect to the function itself rather than an entire file. I personally don't mind } else { or } else if { but I do mind the following:

    Py_ssize_t out_len = 5 * ((bin_len + 3) / 4);
    if (wrap)                   out_len += 4;
    if (!pad && (bin_len % 4))  out_len -= 4 - (bin_len % 4);
    if (width && out_len)       out_len += (out_len - 1) / width;

I prefer clear if (...) {<nl>...<nl>} in this case.

kangtastic · 2025-12-27T18:10:53Z

I personally don't mind } else { or } else if { but I do mind the following:

    Py_ssize_t out_len = 5 * ((bin_len + 3) / 4);
    if (wrap)                   out_len += 4;
    if (!pad && (bin_len % 4))  out_len -= 4 - (bin_len % 4);
    if (width && out_len)       out_len += (out_len - 1) / width;

I prefer clear if (...) {<nl>...<nl>} in this case.

Will do.

Per [1] this will be allowed despite PEP-0399. [1]: https://discuss.python.org/t/accelerator-for-ascii85-base85/105415/3

We are no longer testing both Python and C codepaths for base-85-related functions in base64.

This avoids exposing a `z85` bool parameter. Also update documentation. While we're at it, refer to the encoding as "Base85" instead of "base85".

kangtastic · 2025-12-29T00:55:04Z

The PR has been updated. To summarize the changes:

C code style was updated and modernized
Z85 functions were added to binascii to get rid of the z85 parameter in e.g. binascii.a2b_base85()
pure-Python base-85 codepaths in base64 were removed along with the _base64 module

I also updated the PR description with another round of benchmarks. Notably, the optimizations to binascii.b2a_ascii85() by @serhiy-storchaka are visible on my end as well :)

Regarding C code organization in binascii, I tested separate codepaths for Base85 and Z85, both explicitly by duplicating functions with just the lookup table names changed and by adding the inline keyword to what I have now. With PGO/LTO enabled it doesn't seem to make much of a difference.

Weirdly, Z85 decoding is about 10% slower for me with PGO/LTO enabled. That might mean the Z85 tests actually are causing the compiler to optimize differently, or it might be an artifact of my ancient dev machine or my crude benchmarking methods. In any case the performance gains compared to the pure-Python implementations are still quite substantial so I'm going to leave it at that.

serhiy-storchaka

Fantastic!

I will make final reviews after merging #143262 and #143216 (and maybe some other PRs). Some code, docs and tests can be rewritten after them. Here are some general comments.

serhiy-storchaka · 2025-12-29T09:24:12Z

Modules/binascii.c

+    fold_spaces: bool = False
+        Allow 'y' as a short form encoding four spaces.
+    wrap: bool = False
+        Expect data to be wrapped in '<~' and '~>' as in Adobe Ascii85.
+    ignore: Py_buffer(c_default="NULL", py_default="b''") = None
+        An optional bytes-like object with input characters to be ignored.


I have a question -- why do you use different parameter names than in base64.a85encode()?

I just chose some names that sounded OK to me. I didn't like adobe in base64.a85decode() because it seemed too specific, and there wasn't commonality between binascii and base64 parameter names (lots of legacy code everywhere).

After reading #143262 and #143216 I gather that reusing CPython interned strings is implicitly good practice, so I will try to do that if you prefer.

serhiy-storchaka · 2025-12-29T09:29:57Z

Modules/binascii.c

+        ascii_len -= 2;
+        if (ascii_len >= 2
+            && ascii_data[0] == BASE85_A85_PREFIX
+            && ascii_data[1] == BASE85_A85_AFFIX) {


PEP 7: if the condition takes multiple lines, move { at a separate line.

Suggested change

&& ascii_data[1] == BASE85_A85_AFFIX) {

&& ascii_data[1] == BASE85_A85_AFFIX)

{

Thanks, missed this, will do.

serhiy-storchaka · 2025-12-29T09:44:33Z

Modules/binascii.c

+    Py_ssize_t bin_len = ascii_len;
+    unsigned char this_ch = 0;
+    for (Py_ssize_t i = 0; i < ascii_len; i++) {
+        this_ch = ascii_data[i];
+        if (this_ch == 'y' || this_ch == 'z') {
+            bin_len += 4;
+        }
+    }
+    bin_len = 4 * ((bin_len + 4) / 5);


This calculation is not accurate, because zs and ys already accounted in the total number of characters. It is also possible to get an integer overflow on 32-bit platform -- try to decode a string of 2**29 zs.

Count separately the number of zs and ys, then the output size is (bin_len - count + 4) / 5 * 4 + count * 4, but check for integer overflow.

Could you explain what you mean? z and y are respectively equivalent to !!!!! and +<VdL, so it's correct to add 4 to ascii_len for each one encountered.

To be thorough I wrote the following to investigate if there are differences between the current and proposed output length calculation. It prints diffs: 0.

#include <stdio.h> int main() { int diffs = 0; for (int ascii_len = 1; ascii_len <= 1024; ascii_len++) { for (int count_yz = 0; count_yz <= ascii_len; count_yz++) { /* Current output length calculation */ int adj_ascii_len = ascii_len + 4 * count_yz; int bin_len = 4 * ((adj_ascii_len + 4) / 5); /* Proposed output length calculation */ int bin_len_2 = (ascii_len - count_yz + 4) / 5 * 4 + count_yz * 4; if (bin_len != bin_len_2) { printf("ascii_len %d count_yz %d bin_len %d bin_len_2 %d\n", ascii_len, count_yz, bin_len, bin_len_2); diffs++; } } } printf("diffs: %d\n", diffs); return 0; }

I didn't check for integer overflow because the rest of binascii doesn't, but I can add it.

serhiy-storchaka · 2025-12-29T09:52:45Z

Modules/binascii.c

+        Allow 'y' as a short form encoding four spaces.
+    wrap: bool = False
+        Expect data to be wrapped in '<~' and '~>' as in Adobe Ascii85.
+    ignore: Py_buffer(c_default="NULL", py_default="b''") = None


None is not acceptable value, isn't? Use b''.

If the signature of a2b_ascii85(string, /, *, fold_spaces=False, wrap=False, ignore=b"") was ignore=None, this would be acceptable. Because it isn't, this clinic input should be ignore: Py_buffer(c_default="NULL", py_default="b''") = b'' instead. Is that what you meant?

serhiy-storchaka · 2025-12-29T10:01:49Z

Modules/binascii.c

+        Emit 'y' as a short form encoding four spaces.
+    wrap: bool = False
+        Wrap result in '<~' and '~>' as in Adobe Ascii85.
+    width: unsigned_int(bitwise=True) = 0


bitwise=True make it to wrap, so 2**32 is interpreted as 0.

There is also no benefit of restricting the range to the C's int, it have to support sys.maxsize. So use size_t here. We can also use a special converter, because the current Python code does not have limitation, and negative values interpreted as 1 (although this is an implementation detail, not documented and not tested, so it is not necessary to support this).

I'll investigate this further and either use size_t or a custom converter.

serhiy-storchaka · 2025-12-29T10:03:21Z

Modules/binascii.c

+    }
+
+    /* Allocate output buffer.
+       XXX: Do a pre-pass above some threshold estimate (cf. 'yz')?


I do not think it is worth it.

serhiy-storchaka · 2025-12-29T10:10:46Z

Modules/binascii.c

+    data: ascii_buffer
+    /
+    *
+    strict_mode: bool = False


Do we need this? It is always True in base64. strict_mode=False is legacy.

Maybe not so legacy, a strict_mode parameter was added to binascii.a2b_base64() in #24402 for what seem like good security-related reasons that are possibly relevant for binascii.a2b_base85() and binascii.a2b_z85() as well.

serhiy-storchaka · 2025-12-29T10:12:12Z

Modules/binascii.c

+    *
+    pad: bool = False
+        Pad input to a multiple of 4 before encoding.
+    newline: bool = True


Do we need this? It is always False in base64. newline=True is legacy.

For this one I agree we probably don't really need it. I put it in following the example of binascii.b2a_base64(). Note that binascii.b2a_uu() always appends a newline but binascii.b2a_hex() doesn't. If you prefer I can remove it.

No performance changes. Base85 tables were probably already aligned.

Include an integer overflow check for Ascii85.

Performance gains of up to 8% for a2b_ascii85() and 25% for a2b_base85() and a2b_z85() were observed.

kangtastic · 2026-01-18T05:14:51Z

The PR has been updated to address most reviewer comments. I even found some minor decoding performance gains. A bit more polish and this one will be done!

bedevere-bot added the awaiting review label Mar 16, 2023

kangtastic changed the title ~~Add Ascii85 and base85 support to binascii~~ gh-101178: Add Ascii85 and base85 support to binascii Mar 16, 2023

bedevere-bot mentioned this pull request Mar 16, 2023

base64.b85encode uses significant amount of RAM #101178

Open

arhadthedev added the stdlib Standard Library Python modules in the Lib/ directory label Mar 23, 2023

kangtastic force-pushed the gh-101178-rework-base85 branch from 71f1955 to 7b4aba1 Compare March 19, 2024 09:27

kangtastic force-pushed the gh-101178-rework-base85 branch from 7b4aba1 to 05ae5ad Compare April 21, 2025 05:16

kangtastic changed the title ~~gh-101178: Add Ascii85 and base85 support to binascii~~ gh-101178: Add Ascii85. base85, and Z85 support to binascii Apr 21, 2025

kangtastic changed the title ~~gh-101178: Add Ascii85. base85, and Z85 support to binascii~~ gh-101178: Add Ascii85, base85, and Z85 support to binascii Apr 21, 2025

AA-Turner reviewed Apr 24, 2025

View reviewed changes

Lib/base64.py Show resolved Hide resolved

kangtastic added 5 commits April 26, 2025 06:37

Restore base64.py

aa06c5d

Test both Python and C codepaths in base64

6c0e4a3

This is done differently to PEP-0399 to minimize the number of changed lines.

Match behavior between Python and C base 85 functions

ce4773c

As we're now keeping the existing Python base 85 functions, the C implementations should behave exactly the same, down to exception type and wording. It is also no longer an error to try to decode data of length 1 mod 5.

Add Z85 tests to binascii

4072e3b

Update generated files

bc9217f

AA-Turner reviewed Apr 27, 2025

View reviewed changes

Lib/_base64.py Outdated Show resolved Hide resolved

AA-Turner reviewed Apr 27, 2025

View reviewed changes

Lib/base64.py Outdated Show resolved Hide resolved

AA-Turner reviewed Apr 27, 2025

View reviewed changes

Lib/test/test_base64.py Outdated Show resolved Hide resolved

kangtastic added 4 commits April 27, 2025 19:55

Avoid importing functools

2c40ba0

Importing update_wrapper() from functools to copy attributes is expensive. Do it ourselves for only the most relevant ones.

Avoid circular import in _base64

fd9eaf7

This requires some code duplication, but oh well.

Do not use a decorator for changing exception type

4746d18

Using a decorator complicates function signature introspection.

Test Python and C codepaths in base64 using mixins

d075593

Do we really need to test the legacy API twice?

Optimize binascii.b2a_ascii85().

01df442

serhiy-storchaka mentioned this pull request Dec 27, 2025

Support multiline output in binascii.b2a_base64() and base64.b64encode() #143214

Closed

Apply suggestions from code review

7885918

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

kangtastic added 8 commits December 28, 2025 07:35

Update C style to more closely adhere to PEP-7

1e928e3

Remove pure-Python base-85-related codepaths in base64

2691a0a

Per [1] this will be allowed despite PEP-0399. [1]: https://discuss.python.org/t/accelerator-for-ascii85-base85/105415/3

Remove now-unnecessary _base64 module and fix tests

b9d27bd

We are no longer testing both Python and C codepaths for base-85-related functions in base64.

Separate Z85 from Base85 on the Python API side

780517a

This avoids exposing a `z85` bool parameter. Also update documentation. While we're at it, refer to the encoding as "Base85" instead of "base85".

Fix tests after separating Base85 from Z85

bc9a66d

Merge branch 'main' into pythongh-101178-rework-base85

dc1d3fc

Update generated files after merging main

c5de5a1

Update Misc/NEWS.d and Misc/ACKS

3bb3b18

kangtastic changed the title ~~gh-101178: Add Ascii85, base85, and Z85 support to binascii~~ gh-101178: Add Ascii85, Base85, and Z85 support to binascii Dec 29, 2025

Update generated files again

6f09fa8

Fix typo in NEWS entry

6d8f897

serhiy-storchaka reviewed Dec 29, 2025

View reviewed changes

serhiy-storchaka and others added 8 commits January 14, 2026 14:53

Merge branch 'main' into pythongh-101178-rework-base85

3582492

Move the NEWS entry to the correct section.

879dd86

Minor cleanups, align lookup tables to 64 bytes (NFC)

3cdc3c5

No performance changes. Base85 tables were probably already aligned.

Allow up to sys.maxsize output length when encoding base 85

8adaf2c

Fix Ascii85 test from mainline

2b2ecc4

Allow up to sys.maxsize output length when decoding base 85

da165d1

Include an integer overflow check for Ascii85.

Defer base 85 overflow check during decoding

bf32f99

Performance gains of up to 8% for a2b_ascii85() and 25% for a2b_base85() and a2b_z85() were observed.

Merge branch 'main' into pythongh-101178-rework-base85

74f6ceb

	&& ascii_data[1] == BASE85_A85_AFFIX) {
	&& ascii_data[1] == BASE85_A85_AFFIX)
	{

Uh oh!

gh-101178: Add Ascii85, Base85, and Z85 support to binascii #102753

Are you sure you want to change the base?

gh-101178: Add Ascii85, Base85, and Z85 support to binascii #102753

Uh oh!

Conversation

kangtastic commented Mar 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Synopsis

Discussion

Benchmarks

Uh oh!

ghost commented Mar 16, 2023 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kangtastic commented Mar 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

python-cla-bot bot commented Apr 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kangtastic commented Apr 21, 2025

Uh oh!

sergey-miryanov commented Apr 21, 2025

Uh oh!

kangtastic commented Apr 21, 2025

Uh oh!

Uh oh!

kangtastic commented Apr 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

picnixz commented Dec 26, 2025

Uh oh!

serhiy-storchaka commented Dec 27, 2025

Uh oh!

kangtastic commented Dec 27, 2025

Uh oh!

picnixz commented Dec 27, 2025

Uh oh!

kangtastic commented Dec 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kangtastic commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

serhiy-storchaka left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kangtastic Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kangtastic commented Mar 16, 2023 •

edited

Loading

ghost commented Mar 16, 2023 •

edited by ghost

Loading

kangtastic commented Mar 19, 2024 •

edited

Loading

python-cla-bot bot commented Apr 18, 2025 •

edited

Loading

kangtastic commented Dec 27, 2025 •

edited

Loading

kangtastic commented Dec 29, 2025 •

edited

Loading

kangtastic Dec 30, 2025 •

edited

Loading