GeezerVison

Add base32 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
base32 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: pythongh-146192

- Use the new `alphabet` parameter in `binascii`
- Remove `binascii.a2b_base32hex()` and `binascii.b2a_base32hex()`
- Change value for `.. versionadded::` ReST directive in docs for
  new `binascii` functions to "next" instead of "3.15"

serhiy-storchaka left a comment

- Update docs to refer to "Base 32" and "Base32"
- Update docs to better explain `binascii.a2b_base32()`
- Inline helper function in `base64`
- Add forgotten tests for presence of alphabet module globals

serhiy-storchaka left a comment

- Revise docs
- Add whatsnew entry
- Minor whitespace change in tests

Referring to a group of 8 bytes as an "octet" may cause
confusion, because the term is already commonly used in
some languages to refer to a group of 8 bits (i.e. a byte).

"Octa" is a suitable preexisting alternative for a group of
64 bits [1] (used by Knuth himself, at that). "Octad" was
considered, but it, too, historically refers to a byte.

Also rename "quintet" to "quint". "Pentad" was considered,
but it historically refers to a group of 5 bits.

[1] https://en.wikipedia.org/wiki/Units_of_information

serhiy-storchaka left a comment

- Reword NEWS.d entry to "Base32" instead of "base-32".
  No prior entries have ever mentioned "base-64", etc.,
  but they have mentioned "Base64", etc., so this is
  more consistent.

- Reword whatsnew entry to "Base32" instead of "Base 32".
  No prior entries have ever mentioned "Base 64", etc.,
  and there is an entry a little further up mentioning
  "Ascii85, Base85, and Z85", so this is more consistent.

- Add a whatsnew entry in Optimizations > base64 & binascii
  section.

- Whitespace change in `binascii.c`.

When decoding invalid length (1, 3 or 6 mod 8) + no padding,
mention the invalid length instead of the improper padding in
the exception message to match what the base64 decoder does.

Additionally, move the logic for setting the exception message
(back) outside the "slow path" loop; if we do end up checking
canonicity of decoder input, it will feel (subjectively) better
to have several checks grouped together after the loop.

gpshead left a comment