Python. Kata wants us to sort it based on numerically descending 9-1 which makes sense. what gets confusing is the alphabetically part. From my knowledge sorted() sorts a-z, so ascendingly. So my sorted list would be sorted 9-1 but when two conflict for same rank it would put a before b. Made me a bit confused. I'd say just sort ascendingly from 1-9 to simpify the sorting process, cause it's not really important. Other than that pretty nice, especially the use of json data.

Also at some point in my attempting the tests threw an error from serverside saying something about not supporting > with None type. Only happened once though.

the markdown in the description mixes code blocks with language blocks, resulting in confusing rendering, e.g.:

`getWidth()` return the width of the `Block`

either the languages tags should be replaced by conditional ones, or the backticks surrounding function names should be erased and the specification commented out

python new test framework

python new test framework is required. updated in this fork

C#: method name should be PascalCase (Please refer to implementation of backward compatibility here )

I believe there is a bug in the test suite:
assertion failed: (left == right)
left: ([22, 13, 10, 8, 7, 6, 6, 5, 5, 5, 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1], 28),
right: ([22, 13, 10, 8, 7, 6, 6, 5, 5, 5, 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2], 199)

The remainder can never be a larger number than the index. I pass the initial test but I fail on two other tests and it seems that these tests are wrong. I'm in RUST.

As per my comment below, the handling of uncertainty in this kata is pretty weird. Solutions are required to deliver answers with higher precision than the inputs, and therefore coders must either:

1. Think about the numerical analysis of their solution (not really a 7-kyu thing)
2. Fiddle around with the algebra until they stumble on a correct solution or get lucky with the random tests (not great for learning IMO)

For reference the uncertainty on the volume of a sphere with radius 1000+-0.005 (rounded to 2DP as in this kata) is about +-157, whereas the kata asks for an answer accurate to +-0.000005

I suggest one of the following be applied:

1. Test answers to within a percentage of the expected value rather than to a static 5DP; Gaussian error approximation for the most complex of these calculations is about 0.03%, which would prevent most issues.
2. The description be updated to mention the need for accuracy, and some hints about how to do that (e.g. avoid rounding on intermediate values) could be added.

My all test past but when i try atemp my solution i had 2 errors.

Test Failed
Expected string length 9 but was 12. Strings differ at index 5.
Expected: "[5, 2][4]"
But was: "[5, 2, 1][0]"
----------------^

This is a poorly written test. My solution is correct and there is a wrong string calculation on the test...

Python should be updated to new test framework

Note: approve Ruby translation first

In python the function should return a tuple.

Test cases marked as True or as False by a few decimals points, depending on whether some multiplication is put first or last. That is a serious bug. Test should not exactly compare floats !

Rust translation

Rust translation.

( JS, possibly others )

Performance requirements of the translation are not in line with intent of the Python original, or with ranking.

the formula in the description is incorrect: summation is from 0 to n, not from 1 to n