I like your sete. Good thinking!

I'm confused as to why this works..

This can be calculated exactly

For example:

[0] = 1 (always starts here)

[1] = P(1) (probability of rolling a 1) = 1/6

[2] = P(2) + P(1)*P(1) = 1/6 + 1/36 (you can get here by rolling a 2 or rolling 2x1s)

...

It's a combinatorial problem and should have a solution as a function of n

If this was put into beta today in Python, it would probably get a 6kyu rating...

added input contraints. 2 <= len(lst) <= 100

Removed now.

Empty list as input is not ruled out by the description. Existing solutions behave completely different at empty list input (including True, False and throwing exceptions).

All values are less than the length of the list (i.e., they are valid indices).

This test case is in both sample tests and actual tests:

test.assert_equals(full_cycle([3, 0, 4, 2]), False)

Correct, it shouldn't really show up in the description when you are solving in a different language... But it is quite common that you see something like "if string is empty return false (null in null-lang, 0 in 0-lang)" etc.

Done.

Haskell is a computer programming language, the comments are to exclude the Haskell implementation from certain attributes mentioned.

The DNA of a Haskell has been discovered not to be a string but a list of bases, but better research is still required.

No help here?

What part do you want explanation on?

The source of the problem seems to be elsewhere, when you use the function gettype with the operator !==. Check the documentation to see how they are supposed to work.