Max (or near max) indexes should be tested for all bases, otherwise invalid solutions can pass, that don't check high enough primes (e.g. base 30, k = 150)

did exactly the same, some 30 years ago, on the C64 ;-)

Also updated the description, adding:

... pad it so that the ASCII block is aligned, as in the below example

As written in the description:

If the last line is shorter than 16 bytes, then replace the byte values with spaces, but trim the trailing spaces from the end of the line.

The ascii block (on the right) should be aligned, like this:

00000040: 08 4a 12 25 79 c2 dd 31 6b b8 77 74 4b 68 4b d4  .J.%y..1k.wtKhK.
00000050: db 4e 92 09 d5 4c 9f 0b fd a9 d1                 .N...L.....

and not messed up, like this:

00000040: 08 4a 12 25 79 c2 dd 31 6b b8 77 74 4b 68 4b d4  .J.%y..1k.wtKhK.
00000050: db 4e 92 09 d5 4c 9f 0b fd a9 d1  .N...L.....

Oh, and note that 240+ people solved it in python without such a problem, so it's not an issue of the kata.

Cheers

For some more fun and challange, try the code golf version too!

Test case added - some solutions were invalidated.

I could reject solutions with a \n in them, but that kills a part of the creativity, and I value the different approaches that you can learn from.

I looked for short solutions in the python versiob of the original kata, but didn't find any. Maybe in other languages there were such solutions. I set the size limit so that a simple approach (remove extra spaces + use 1-letter variables) doesn't pass. I will consider lowering the size limit a little.

72 bytes

Great job turning it into a lambda! ;-)

80 bytes

82 bytes, combining my other solution with Fbasham's approach

Nice approach, and can be made a lot shorter --> 91 bytes

99 bytes with a slightly different approach

96 in the fork

106 bytes

102 in the fork

fixed

Wow, I didn't expect this!