hahahhaha

I've found this with the Java solutions as well. A test for Long.MAX_VALUE fails for many of the solutions and the description doesn't specify an upper limit for prod.

    @Test
    public void testMaxLong() {
        long[] r = new long[] {2971215073L, 4807526976L, 0};
        assertArrayEquals(r, ProdFib.productFib(Long.MAX_VALUE /* 9223372036854775807 */));
    }

lol this one made me laugh a bit thanks for that

removed => isinstance is now allowed

Alright, alright! Be patient! These things take some time.

Approved.

On second thought, I think it's counter-productive to put the anticheat stuff in preloaded; anything that is public there (and it has to be, in order to be visible to the test module) is visible to the user solution. The whole thing should live inside the anti-cheat module in the test suite, making it inaccessible to the user solution.

Updated the translation to new edition and Rust version so that it compiles again. However, I don't really understand test generation (can't parse the various recursive macrorules) and anticheat well enough to approve myself.

i added the following to the description:

If you get a frequency list with one or less elements, return null/None/Nothing, depending on your language.

Re-raised (and updated and expanded for clarity).

Please make it clearer how code should 'reject' a frequency table with just one or no elements. Currently the description states:

Note: Frequency lists with just one or less elements should get rejected. (Because then there is no information we could encode, but the length.)

There is no clear definition of 'reject' across programming languages. Make it explicit what should happen in such cases.

For the Python version, the starter text (the template solution text you get when you start training) confuses matters too, as it tells you only str is expected:

# takes: [ (str, int) ], str; returns: String (with "0" and "1")
def encode(freqs, s):
    return ""

# takes [ [str, int] ], str (with "0" and "1"); returns: str
def decode(freqs,bits):
    return ""

Where the input should be rejected, the tests expect None here, which is definitely not a str object. A seasoned Python developer might reasonably expect to have to raise an exception here, as that's the ideomatic way of rejecting bad input in Python. With no further clarity in the description and the comments stating a str return is expected, that's a perfectly reasonable assumption to make.

So, for Python at least, please update the returns lines in the template:

# takes: [ (str, int) ], str; returns: str (with "0" and "1"), or None when rejecting
def encode(freqs, s):
    return ""

# takes [ [str, int] ], str (with "0" and "1"); returns: str, or None when rejecting
def decode(freqs,bits):
    return ""

(This issue was re-raised by request)

Please reraise your issue.

I think you may have misunderstood what I asked for. While None may not be entirely idiomatic in Python, I didn't actually ask that to be changed.

I asked for the return lines to be updated, part of the initial Python code that you see in the Solution editor pane when you start training. There, the comments claim that encode() and decode() only return str and I'm strongly suggesting that you want to add , or None when rejecting to those lines.

I also asked for the phrasing "rejected" to be clarified. That verb doesn't mean anything when it comes to a problem specification. Reject the value how? Please read my remarks on exceptions in Python in that light, I gave context to what I would normally have expected the problem to treat "rejecting" an input. Returning None is fine too here, but you need to make this explicit. This isn't something that you can simply bury with an excuse of this being an imperfect translation between different programming languages.

I note I'm not the only one to have reported this issue either, see this report, which could easily have been avoided if there wasn't this directly conflicting text that claims only str is to be returned.

Finally, and very ironically, dismissing feedback on your Kata with Broaden your horizons is incredibly close-minded. Learn to communicate better, being dismissive and rude is no way to treat anyone, especially not those that took the time to give you feedback.

Not gonna happen. The kata's specs are adapted from Haskell, where None is perfectly idiomatic - you can read the example tests to find out what is expected.

I'm not saying it's ideal, but in an imperfect world specs are sometimes adapted from other languages. Broaden your horizons.

Closing.

Added a clear remark about the wrapping nature, plus the "lfl" test suggested by monadius.

Thank you! That's a wonderful post. Bookmarked!