Thank you all for the thoughtful feedback!

Regarding the batch input format, you're absolutely right to question whether this provides meaningful differentiation. The idea here is to simulate realistic scenarios where multiple modular exponentiations are needed at once (such as in cryptographic systems or batch computations). While the function could technically map over a single-triplet version, the goal is to encourage writing a solution that directly handles structured batch input, which is not the focus in the kata Mauro referenced (https://www.codewars.com/kata/52fe629e48970ad2bd0007e6).

To address this more clearly:

I’ll revise the example solution to highlight why handling the list directly matters.

I’ll also make the performance test case more explicit to show where a naive ** or Math.pow solution might fail under extreme inputs.

In short: yes, the performance cost of mapping may not always expire, but the design constraint is intentional, to push users to think in terms of scalable solutions.

Again, thank you! These comments really help polish the kata and its clarity for future users.

I also fail so see the difference from single-case handling in the example solution. If the batch processing is a design choice, the example solution should showcase that difference.

Duplicate of (at least) https://www.codewars.com/kata/52fe629e48970ad2bd0007e6

That would make sense if the additional performance were actually required, and mapping individual modpows over the list would timeout. Is it, and does it?

Good catch! I’ve now added a reference implementation of mod_power inside the test suite to avoid this error.
This internal function is only used to compute expected results and won’t affect user solutions.

You're absolutely right. This kata expects the user not to use pow() or **.
I'll make this restriction more explicit in the kata description, and update the tests if needed to catch such usage.

Thanks for your suggestion! However, this kata is intentionally designed to take a list of triplets instead of a single triplet.
It focuses on batch-processing modular exponentiations efficiently, which is slightly different from single-case handling.

The function should receive a single triplet and return the corresponding result.

Do not use built-in power functions ...

Restrictions should be tested.

Traceback (most recent call last):
  File "/workspace/default/.venv/lib/python3.11/site-packages/codewars_test/test_framework.py", line 112, in wrapper
    func()
  File "/workspace/default/tests.py", line 31, in large_exp
    expected = mod_power(a, b, n)
               ^^^^^^^^^
NameError: name 'mod_power' is not defined

Your tests rely on the user also defining this function. Check my solution for what could go wrong by doing that.

kata retired

Also, why is the word retourne in the description?

..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Fix your tests.

It appears to happen in Python only. Java works fine. Don't know about the JS case tho.