Genralized tip:

def kata_solution(arg):
    print(arg)

You'll fail all the test, but usually you'll see the input. (Except, as you'll discover here, not always.)

def kata_solution(arg):
  pass

Often this will help you find out the count of tests. (Although, again not always.)

I was able to reach 65 tests, but still timed out. I suspect we're using the same algorithm (but I've optimized mine as much as possible). I have in mind another algorithm which I think may be faster, but don't have time to implement it at the moment. I'd encourage you to try a different approach. 232 people have solved it in Python, so it should be doable.

No spoilers, sorry. :)

Very polite explanation tx

Looks great.

Closing now.

OK, how's this description now?

Alternatively, I could input and output multisets. That would be better technically, but the LC specification would be nigh on impossible. Lists are so much nicer to work with.

I think that's a lot clearer. It makes it clear that elements can't be re-used but that values may appear more than once.

Alternatively, you could have the output be a value:multiplicity mapping which might be more readable than a list of indices and is easy to check.

I just forgot to update call syntax to JS and Python ( I wrote LC and Haskell first ). I'll fix that myself. ETA: done

Idiomatic Python would mainly lose the semicolons and insert a million newlines?

Problem is Python doesn't hoist, so the actual tests have to be at the bottom. I'd love it if you could fix that, but the only solution for that, that I know of, is importing all helpers from Preloaded, then duplicating them at the bottom of the test block, introducing duplicated code that has to be kept synced - which IMO is worse.

Python assertion messages are very hard to parse for us, f x y -> actual is very easy to interpret as f x y -> expected. Curried prefix notation is probably also going to confuse quite a lot of Python users. I would suggest something along the lines of For f(x, y): actual was returned, however <failure message>.

The tests are also very hard to read, I can rewrite them as more idiomatic Python if you'd like (whilst preserving the stop-on-failure etc).

Clever idea, but I'd rather not do that. It makes output too unreadable.

You can always ask for the set of indices of the elements instead, that's always going to be a set by definition.

And if I don't change the requirements, the middle part of that could become

The subset must consist of unique ( by index ) list elements. If a particular value occurs more than once in the input list, you can use it up to as many times as it occurs. The empty subset ..

The first and last part don't change.

Would that be as clear as what you wrote? Or does "subset" cause difficulty that "subsequence" does not? I can imagine "subsequence" more intuitively conveys you cannot reuse elements by index.

I don't know if it is needed to change the kata in order to fix the description, but if that is the new requirement of the kata:

Given a possibly empty list... return a subsequence of the list which sums to the target number...

The subsequence must consist of elements from the original list without re-ordering, but the elements need not be contiguous (i.e., skipping elements is fine). ((Possible examples here)) An empty subsequence is defined as summing to zero. ((Maybe a per-language bit about the form of the returned subsequence.))

The target will never ...

I think this uses clear terminology, but also restates the definition in a way that (I hope) avoids potential confusion.

I can make it a requirement. Makes testing simpler even.

But what would the description then have to be? It's about the description, ultimately.

That'd certainly be clearer, and even if someone is led astray by it (since it isn't a strict requirement), they can still arrive at a solution.