Base64 decode with altchars still accepts non-altchars

[Anonymous3-a]

Bug report

Bug description:

If you run

>>> import base64
>>> base64.b64decode("/+/+")

it gives

b'\xff\xef\xfe'

This is expected.
If you run

>>> base64.b64decode("_-_-", altchars="-_")

It gives the same output.
This is expected.
However, if you run

>>> base64.b64decode("/+/+", altchars="-_")

It also gives the same output.
This is not expected.

This is concerning because I'm trying to use file safe base64 (urlsafe_b64decode/encode do not have validate arg, which I need). I can work around this by also checking for / and + as well.

CPython versions tested on:

3.9, 3.11

Operating systems tested on:

Linux, Other

Linked PRs

• gh-125346: Add more base64 tests #141061
• [3.14] gh-125346: Add more base64 tests (GH-141061) #141130
• [3.13] gh-125346: Add more base64 tests (GH-141061) (GH-141130) #141133
• gh-125346: Fix decoding with non-standard Base64 alphabet #141128
• Remove duplicated tests in test_base64 (gh-125346) #141153

[ImFeH2]

It's intentional behavior that was decided upon years ago. found the following as i'm trying to fix, which related to a commit in 2016.

cpython/Lib/test/test_base64.py

Lines 266 to 269 in 4a943c3

	# Normal alphabet characters not discarded when alternative given
	res = b'\xFB\xEF\xBE\xFF\xFF\xFF'
	self.assertEqual(base64.b64decode(b'++[[//]]', b'[]'), res)
	self.assertEqual(base64.urlsafe_b64decode(b'++--//__'), res)

But I think the original alphabet should be discarded because an alphabet should always remain singular. if alternative characters are provided, the original ones should be deprecated to avoid confusion and maintain consistency.

[picnixz]

Should we document this behaviour if it is not already the case? cc @serhiy-storchaka

[picnixz]

cc @vadmium as the one who wrote this test in 2016

[serhiy-storchaka]

We should look at the discussion when that feature was added, but I think it is not intentional behavior.