The beta process exists to resolve issues before potential approval. While my solution might be ridiculous to you, input modification of mutable objects is an issue. Anyways, if you stick around long enough on codewars, that and not having random tests come up a lot in beta testing.

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.

How is this better then capitalize?

Do not use rounding or formatting floating point numbers to string with fixed precision, this is a bad practice

Use assert_approx_equals

https://docs.codewars.com/authoring/recipes/floating-point#do-not-use-rounding-or-stringification-to-work-around-problems-with-precision

from random tests:

polar_form(31531-494i) = > '31534.8695e^(6.2675*i)' should equal '31534.8695e^(3.1259*i)'

Fixed.

polar_form(4+3i) = > '5e^(0.6435*i)' should equal '5e^(0.9273*i)'

This is incorrect, as are many of the tests.
5e^(0.6435*i) => 4+3i
5e^(0.9273*i) => 3+4i