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

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

Synopsis

Add Ascii85 and base85 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 April 20, 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.14.0a7+ commit 78cfee6f09
# ./configure --enable-optimizations --with-lto

# With this PR
$ time ./python bench_b85.py 64
b64encode : 67108864 b in 0.084 s (763.340 MB/s) using 42.667 MB
b64decode : 89478488 b in 0.230 s (371.074 MB/s) using 56.889 MB
a85encode : 67108864 b in 0.190 s (336.115 MB/s) using 0.000 MB
a85decode : 83886080 b in 0.216 s (370.605 MB/s) using 0.000 MB
b85encode : 67108864 b in 0.072 s (887.955 MB/s) using 0.000 MB
b85decode : 83886080 b in 0.175 s (457.224 MB/s) using 0.000 MB
z85encode : 67108864 b in 0.072 s (891.721 MB/s) using 0.000 MB
z85decode : 83886080 b in 0.174 s (460.582 MB/s) using 0.000 MB

real    0m2.231s
user    0m2.064s
sys     0m0.156s

# Unmodified
$ time ./python bench_b85.py 64
b64encode : 67108864 b in 0.082 s (781.718 MB/s) using 42.667 MB
b64decode : 89478488 b in 0.237 s (360.686 MB/s) using 56.889 MB
a85encode : 67108864 b in 7.492 s (8.543 MB/s) using 2664.406 MB
a85decode : 83886080 b in 14.264 s (5.609 MB/s) using 3332.254 MB
b85encode : 67108864 b in 7.181 s (8.912 MB/s) using 2664.404 MB
b85decode : 83886080 b in 8.486 s (9.427 MB/s) using 3332.254 MB
z85encode : 67108864 b in 7.343 s (8.715 MB/s) using 2664.102 MB
z85decode : 83886080 b in 8.778 s (9.113 MB/s) using 3332.254 MB

real    9m2.346s
user    8m47.248s
sys     0m12.460s

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?

Lib/base64.py

kangtastic · 2025-04-29T03:26:09Z

PR was accidentally closed due to misclicking on mobile. There should be a confirmation dialog or something 😅

serhiy-storchaka · 2025-12-26T09:40:19Z

Thank you for your PR, @kangtastic. This looks very interesting. The speed was increased by 100 times, this is impressive. Initially we did not bother to implement these codecs in C, because they are non-standard, and the expected use was just for few kilobytes. But it seems people use them for larger data.

I resolved conflicts and fixed tests and support of features added since the last update. I am planning to finish the review and land that code in Python.

I managed to speed up Ascii85 encoding by 3 times, it can be almost so fast as Base85. If you don't mind, I'll apply this optimization here.

As for general organization of the code, I think that introduction of the _base64 module is redundant. I understand why you did this, for tests, but the binascii module is a non-optional dependency for base64. If we need to make Base85 support in binascii optional, we should simply test if binascii.a2b_ascii85 etc exist in base64.py. I am not sure that it is worth the hassle. I asked others for opinion: https://discuss.python.org/t/accelerator-for-ascii85-base85/105415 .

Also, instead of the boolean z85 parameter, it is better to add separate functions. It could be even better to generalize the functions to work with an arbitrary alphabet, but it is not easy for decoders. If we are going this way, we have to generate the decoding table in Python, or implement caching in C.

kangtastic · 2025-12-26T13:58:27Z

Thank you for your PR, @kangtastic. This looks very interesting. The speed was increased by 100 times, this is impressive. Initially we did not bother to implement these codecs in C, because they are non-standard, and the expected use was just for few kilobytes. But it seems people use them for larger data.

Thanks for reviewing, @serhiy-storchaka.

I resolved conflicts and fixed tests and support of features added since the last update. I am planning to finish the review and land that code in Python.

I managed to speed up Ascii85 encoding by 3 times, it can be almost so fast as Base85. If you don't mind, I'll apply this optimization here.

No objections from me. Interested to see how you did it.

As for general organization of the code, I think that introduction of the _base64 module is redundant. I understand why you did this, for tests, but the binascii module is a non-optional dependency for base64. If we need to make Base85 support in binascii optional, we should simply test if binascii.a2b_ascii85 etc exist in base64.py. I am not sure that it is worth the hassle. I asked others for opinion: https://discuss.python.org/t/accelerator-for-ascii85-base85/105415 .

Yes, I originally removed the pure-Python base-85-related function implementations in base64 for the same reasons you mentioned in your discussion thread. I added them back in and created _base64 after @AA-Turner pointed out in the previous review that PEP-0399 requires keeping existing pure-Python implementations alongside new C accelerator modules. If the discussion thread leads permission to remove the Python codepath, I'd be happy with that.

Also, instead of the boolean z85 parameter, it is better to add separate functions. It could be even better to generalize the functions to work with an arbitrary alphabet, but it is not easy for decoders. If we are going this way, we have to generate the decoding table in Python, or implement caching in C.

Regarding generalization for arbitrary alphabets, I didn't think it was necessary given that only Ascii85, Base85, and Z85 are in common use, and Ascii85 is different enough that there are really only two alphabets to be generalized.

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).

picnixz

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

Doc/library/binascii.rst

picnixz · 2025-12-26T15:11:31Z

Lib/_base64.py

+
+
+def _bytes_from_encode_data(b):
+    return b if isinstance(b, bytes_types) else memoryview(b).tobytes()


memoryview(b).tobytes() may raise a generic TypeError here, whereas it is in _bytes_from_decode_data. Should we do it as well?

The discussion by @serhiy-storchaka seems to have been resolved with the conclusion that the pure-Python base-85-related functions from base64 may be removed.

I'll therefore turn base64.a85encode(), etc. into wrappers for the new binascii.b2a_ascii85(), etc. as I had it originally, similarly to how e.g. base64.b64encode() is a wrapper for binascii.b2a_base64().

_base64.py will be removed, since it will no longer be necessary to test against both Python and C implementations of the base-85-related functions. So that makes your concerns for this specific file moot.

However, to follow your comment here a bit:

The type conversion logic is replicated from the existing _85encode() helper function, which itself seems to have replicated the logic from the existing _b32encode() helper function.

The logic in _b32encode(), in turn, seems to be an attempt to replicate the existing binascii facility for input type conversions.

The new additions (base64.a85encode(), etc.) use the existing binascii facility, which raises a more descriptive TypeError instead of a generic one.

Can you or someone else verify that the C type conversion logic in binascii and the Python logic in base64 are equivalent, or at least equivalent enough?

Oh so it was something that was already there. Ok, sorry for the noise. I was more worried about the fact that a TypeError was caught during decoding but not during encoding.

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

Lib/_base64.py

+
+# Functions in binascii raise binascii.Error instead of ValueError.
+
+def a85encode(b, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):


Suggested change

def a85encode(b, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):

def a85encode(b, /, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):

No, the existing Python implementation does not use positional-only parameters. Changing this is a separate issue.

Arf, ok :( I thought it was incorrectly c/c.

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

Lib/_base64.py

+        raise ValueError(e) from None
+
+
+def a85decode(b, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):


Suggested change

def a85decode(b, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):

def a85decode(b, /, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):

picnixz · 2025-12-26T15:20:11Z

Modules/binascii.c

+                state = get_binascii_state(module);
+                if (state != NULL) {
+                    PyErr_SetString(state->Error, "Ascii85 overflow");
+                }


This can be NULL only if:

the state is really missing (mod->md_state == NULL)

'module' is not a module

I don't know when it could be possible for the state to be missing (maybe at interpreter's finalizaation?).

I don't know when it could be possible for the state to be missing (maybe at interpreter's finalizaation?).

Apparently it's possible for state to be missing if an error is already set.

Yeah but this is only if the error is a badargument (that is we didn't give a module).

I think I did it because every other PyErr_SetString(state->) or PyErr_Format(state->) in binascii does it 😅

Maybe someone knows if it's OK to do assert(state != NULL); instead, like some other modules. Separate issue?

Yeah I think it's better to do it in a separate issue.

picnixz · 2025-12-26T15:20:45Z

Modules/binascii.c

+
+    return PyBytesWriter_FinishWithPointer(writer, bin_data);
+
+error_end:


I'd suggest naming this error instead of error_end.

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.

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?

kangtastic closed this Apr 29, 2025

kangtastic reopened this Apr 29, 2025

AA-Turner reviewed Apr 29, 2025

View reviewed changes

Lib/base64.py Outdated Show resolved Hide resolved

Remove leading underscore from functions in private module

6d65fec

serhiy-storchaka self-requested a review December 24, 2025 18:40

serhiy-storchaka added 5 commits December 24, 2025 21:05

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

a241356

Use more modern C API.

0df9a40

Fix tests.

60fbd7c

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

a070887

Fix new tests.

167e83e

picnixz reviewed Dec 26, 2025

View reviewed changes

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

Open

Apply suggestions from code review

7885918

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



		def _bytes_from_encode_data(b):
		return b if isinstance(b, bytes_types) else memoryview(b).tobytes()


		# Functions in binascii raise binascii.Error instead of ValueError.

		def a85encode(b, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):

	def a85encode(b, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):
	def a85encode(b, /, *, foldspaces=False, wrapcol=0, pad=False, adobe=False):

		raise ValueError(e) from None


		def a85decode(b, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):

	def a85decode(b, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):
	def a85decode(b, /, *, foldspaces=False, adobe=False, ignorechars=b' \t\n\r\v'):


		return PyBytesWriter_FinishWithPointer(writer, bin_data);

		error_end:

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

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!

Uh oh!

kangtastic commented Apr 29, 2025

Uh oh!

serhiy-storchaka commented Dec 26, 2025

Uh oh!

kangtastic commented Dec 26, 2025

Uh oh!

picnixz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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!

picnixz commented Dec 26, 2025

Uh oh!

serhiy-storchaka commented Dec 27, 2025

Uh oh!

kangtastic commented Dec 27, 2025

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