Hello,

The common language on codewars is english. The description needs to at least host an english version (end preferably be the only version, actually).

Unpublishing.

Cheers

sample tests are also written incorrectly, actually.

Please read the docs about authoring.

Hi,

• ... why...? I mean, we already have loads of kata about primes...

• the full test suite isn't writtent properly

• the full test suite contains wrong expectations:

  Traceback (most recent call last):
    File "/workspace/default/tests.py", line 19, in test_examples
      self.assertEqual(product_of_two_primes(100), False)
  AssertionError: (2, 5) != False
  

Not an issue a question. Please use the appropriate flag (see codewars docs if needed)

You're not using the input properly (did you see they are dicts?)

Hi,

Not an issue, a question.

I can't see what's the input

You can print them to the console from your solution.

Cheers

spoiler flag...

The fixed tests are not fixed, they are relying on the ref solution. Meaning if the ref solution is wrong, there is no guarantee on the specs. At all.

Also, the fixed tests should hold all the needed data for each test in one place: input data, princ and thief ids, and also the expected output. The sample tests need to also be updated with this.

Who the hell reviewed the random tests and didn't notice THIS:

def create_subgraph(id_, amount_friends, not_possible = set()):
                                       # ^^^^^^^^^^^^^^^^^^^^

some other solutions are only passing the tests from time to time (the current top solution, for example) => something is wrong somewhere.

Note: according to the description ("algorithmic side"), a friendship path thief -> prince -> firend of prince make all of them suspect, while this doesnt look right because the thief himself is a friend (not that problematic), but this also means there is another friend in the friendship path, meaning none can be suspected...? eidt: mmh, the thief is excluded, so I guess that part is ok, but this situation still looks pretty weird. A clarification and a specific fixed test for that is needed, at the very least.

Hi,

Something isn't specified "correctly", apparently, but more importantly, the efficiency tests are using some outputs that are built entirely differently of all the other tests (edit: that, or the problematic case comes up more frequently when the number of nodes is huge): I currenlty have a solution (fast enough) that is passing all the tests, but returns wrong results on some efficiency tests only. Problem being: how am I supposed to find the hidden spec/stuff I misunderstood on inputs with more than 4000 nodes...?

regex groups

Expected:"igPay atinlay siay oolcay"
But was: "giPay nitalay siay loocay"
                             ^^^^

Not an issue, your code doesn't follow the specs.

Congrats, you're now part of the problem...

forward compatibility though

If it breaks, you'd have to fix the tests in one place. Right now, it'd rather be "everywhere".

keep it visible in the tests so solvers can know what happens

Yeah, I was wondering about that. But the current setup is quite unusual and nobody will understand what's happening just by looking at the code. Proof: the message in the thread just below.
I think that, if you wanna get the users "aware", the very best way would be a comment in orange in the description (python language block). Then you can write the tests as you want.
Also, note that those used to read python tests will get almost as much hint about what happens seeing the unusual it_break wrapper (better naming would help -> edit: it_stops_at_first_failure...? x) ) than with a try/except block.

But again, up to you.

If you wanna move the try/except boiler plate to the preloaded section, you can use something like this. The main point would be to remove it from the example tests. Not sure it's worth the effort...
Up to you.

Cheers

EDIT: sec, I'll patch the allow_raise thing, also. Done