This seems to be not fixed still. Do you need any more info, Jake?

Simply change "import string" to "from string import maketrans" in Preloaded Code.

It is imported in preloaded, but 'maketrans', instead of 'string.maketrans', is used in the testcases. My bad. Though, I can't change anything anymore, so a moderator/kata creator needs to fix it.

"Or you have another vision for completing this task?"
Nope, that's exactly what I meant (and did in my solution), just move sort() out of the loop.

That's weird, because I'm seeing it under "published" in my profile.

Have you accepted/approved it?

Added python translation.

Wouldn't this solution be sorting (or trying to) array2 at each iteration of every()? array2 will be sorted after the first one, but there is still going to be a some overhead, especially if those arrays are very large.

Why would you name it _ if you are actually using that argument?

I think he meant that there shouldn't be test cases where 'bounces' variable is outside of this range.

I don't really get the idea behind -1 returns if window height >= building height. I mean, the mother sees the ball zero times, so why not have the function return zero? Yes, it makes the code a whole one line more complicated, but at least the value corresponds exactly to what is decribed in the scenario.
As an extension/update, window height == building height could be counted as a single 'pass'/increment, since the mother sees the ball both bouncing and falling at the same time.

This should be len(greeting) - 1, but it can be omitted anyway, as [1:] will substring from the second element to the last.

There is (unless it was just added recently), but it had null as o1 and undefined as o2, so the third line of your code (typeof o2 !== 'object') returned false.

How is iteration billions and billions of times 'clever'? And on top of that — Best practice. This is literally infinitely slower than a proper gauss solution.

There seems to an issue with your solution (that random tests are compared to)

First of all, you should explicitly say in the description whether you want duplicates in the return list or no.
The issue is regarding the origin of those duplicates.

For example, if a1 = [28, 23, 39, 32, 22, 14, 25, 39, 41, 18, 34, 34, 4, 42, 48, 38, 3, 47, 28, 25, 7, 42, 43, 17]; a2 = [17]; a3 = [16, 31, 40, 40, 13](40 is present twice in the a3), the solution out = [[23, 17, 40], [14, 17, 31]] is marked as incorrect. One would assume that duplicates should then be included in the return list (which most of the if sum in a3 lack).

This is confirmed by the fact that if a1 = [30, 43, 21, 26, 22]; a2 = [2, 15, 4]; a3 = [41, 34, 41, 27, 12] (41 is present twice in the a3), the solution out = [[30, 4, 34], [26, 15, 41], [26, 15, 41]] is marked as correct.

However, if a1 = [34,35,34]; a2 = [49,29,49,47,20,22,29,34,8,2,44,39,0,14,43,21,28]; a3 = [18,42,12,2,0,13] (34 is present twice in the a1), the seemingly correct solution out = [[34, 8, 42], [34, 8, 42]] is marked as incorrect. One would assume that duplicates should then be omitted from the return list. The same happens if there is a duplicate in a2.

This leads to a conclusion that a1 and a2 need to be set'ed, while a3 — not. Please state that in the description or change or own solution.

On a side note, I think you should increase the length (or decrease the spread) of random arrays, as most of the time the correct solution is simply an empty array.

(All of the above examples were taken from the output console directly. Seems weird that no one noticed this in the time this kata has been around.)