Yes, but m is constant and equal to 5.

How exactly is that so? This runs in O(N) time, if N is the length of the string. Also, in O(N) space, as it must store the result somewhere, which is O(N). This is the optimal complexity for this problem.

You may find solutions with better performance in practice, I agree, but not with better time complexity.

In principle, @boegel is right. If you want to count how many elements you can get from a generator, you shouldn't create a list with all of them and then find its length: list(g). This costs a lot, in time and especially in memory, if there are many elements. You should iterate instead through it and just count: sum(1 for _ in g). But yes, I agree with @lechevalier, it doesn't really matter here.

Let's not start this again, please...

It all depends on your definition of "effective". It's very effective for me, because it's one line and much easier to write than using bitwise operators. It's probably less efficient for my computer because it will need 42us to execute it, while your version will take 17us (so what?). If performance was an issue, I wouldn't be coding this in Python. If it was really an issue, I wouldn't use bitwise operators; I'd use something like __builtin_popcount.

The purpose of the exercise depends a lot on the person doing the exercise. Re-inventing the wheel is useful for novices that need practice with the basic structures of a programming language. Experienced users are expected not to re-invent, but use libraries to their benefit, whenever possible.

Yes I found it. I expected something saying "your program crashes with this input", or at least "your program fails to pass the tests and I won't tell you why, figure this out!". I suppose this is the server's fault, not yours.

And this flaw in my code does not deserve any kind of message from the server, either static or dynamic? This is not how it works, right?

Well, as we know, nobody can be really sure about their code. I'm sure enough of mine, given it passes the original tests and it looks correct to me. I'll upload it somewhere and follow up with a spoiler posting, so that you can test it yourself. In any case, even if the code fails some testcase or does not compile properly at the server for some weird reason, I'd expect some message. Every time I try it, I see nothing: pressing the green triangle reveals nothing at all.

For C++ 14, my solution passes the internal tests but I'm getting this every time I "attempt":

https://postimg.org/image/m4hywr24j/

OK, I think the trick to get this working (if you get weird errors when attempting a solution, like I did) is simple: Use semicolons in your function!

I believe my explanation is correct. In Haskell, mod does not give negative results, therefore:

((8::Int) ^ (21::Int)) `mod` 10 == 2

I'm still getting the same thing:

Falsifiable (after 33 tests and 6 shrinks): 
expected: 7
 but got: 3
NonNegative {getNonNegative = 7}
NonNegative {getNonNegative = 23}

It is:

((7::Integer) ^ (23::Integer)) `mod` 10 == 3
((7::Int) ^ (23::Int)) `mod` 10 == 7

Please, believe me and add a type annotation for Integer to the property-based tests.

I don't know about other solutions. I tried this again and this is what I'm getting:

Screen Shot 2016-11-23 at 22.19.17.png

It tries to test with [8, 21] and it says: "expected 2, got 8".
The truth is that 8^21 = 9223372036854775808, so the correct answer is 8.
For the reason I explained, it expects a wrong answer of 2.

In Haskell, I believe that the tests are wrong. You're testing that:

lastDigit [x, y] = (x ^ y) `mod` 10

Unfortunately, you're doing this for type Int, not Integer. Therefore, e.g., if you take x = 12 and y = 18, you have:

(12 :: Int) ^ (18 :: Int) = 8176589207175692288

because of overflowing, and you wrongly expect the result to be 8. The correct result is 4 because:

(12 :: Integer) ^ (18 :: Integer) = 26623333280885243904

Similarly for other properties involving lists with more than two numbers. Please, fix this ASAP, the kata is not solvable in Haskell without circumventing this!