very nice!

Thanks! :)

approval time then :)

Don't feel bad, your solution is quite neat and readable, props to you.

It took me quite a few hours to make it and I had never tried this "micro-optimization genre", so I'm glad you apprciate it.

I also don't really know what the rating should be. Maybe 4 kyu, but I honestly have no idea.

I don't like the idea of returning all possible paths. Many existing solutions do not construct paths explicitly and these solutions are much faster than solutions which enumerate all paths. With the current constraints, the number of paths is not big. But if the upper bound of target_num is increased then the number of path will become quite large and it will be infeasible to return all possible paths.

I can already see users posting comments: why is the expected result 73 instead of 72? That's the problem with the result being a black box magic number. Why not expect the full progress on each path taken as result?

find(1, 7) -> 5

expect lists of tuples instead, each list is a path, each tuple contains the operation picked, and the intermediate result after applying that operation

[
  [(1, 4), (1, 7)], 
  [(2, 2), (2, 4), (1, 7)], 
  [(2, 2), (3, 4), (1, 7)],
  [(3, 2), (2, 4), (1, 7)], 
  [(3, 2), (3, 4), (1, 7)]
]

Thanks for positive feedback!

fixed

Thank you very much for your feedback, it is valuable to me! I have a few ready-made ideas on the topic of information security in stock, so look forward to it soon)

you lost me right after 'suppose'