Note: This kata uses the non-padding version ("=" is not added to the end).

Some reading will help

Just like how alphabets are handled.

I have this problem:

Traceback (most recent call last):
File "/workspace/default/.venv/lib/python3.10/site-packages/codewars_test/test_framework.py", line 112, in wrapper
func()
File "/workspace/default/tests.py", line 52, in __
test.assert_equals(from_base_64(s), expected)
File "/workspace/default/solution.py", line 7, in from_base_64
a = base64.b64decode(b)
File "/usr/local/lib/python3.10/base64.py", line 87, in b64decode
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

What should I do to fix it?

I really don't remember what this was about, but are you referring to this?

Note: This kata uses the non-padding version ("=" is not added to the end).

Because I think that must have been added to the description after I had written the comment.

This does not confront to standards in 2023 ~!

Sure, that's the misfortune of badly specified katas...

as you can see there are many issues about the padding problem; basically in JS the builtin decode function is lenient and will handle encoded strings with no padding, but in Python this throws an error. I dont know what was the author intent, the sentence about the padding got added to the description by someone else years after the kata was created. builtins for all languages will also generate padding when encoding.

i dont know what's the best course of action to salvage the kata; it seems unfair to invalidate hundreds of solutions because specs were unclear.

Is this enough? https://www.codewars.com/kumite/626bdabb882af20017494efb?sel=626bdabb882af20017494efb

Note: This kata uses the non-padding version ("=" is not added to the end).

This is enforced in Python, but not in C# and JavaScript

the kata supports Swift 5.3 as of now

Removed + description unified.

there are several flavors of base64 and in this kata padding is not required for either encoding or decoding. the description says :

Note: This kata uses the non-padding version ("=" is not added to the end).

re-raised with language details

re-raised as an issue