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):
# takes [ [str, int] ], str (with "0" and "1"); returns: str
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):
# takes [ [str, int] ], str (with "0" and "1"); returns: str, or None when rejecting
(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.
, or None when rejecting
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.
Added a clear remark about the wrapping nature, plus the "lfl" test suggested by monadius.
Thank you! That's a wonderful post. Bookmarked!
This comment is hidden because it contains spoiler information about the solution
Bump It's been a few months, please review this translation!
You misunderstood what "unclean termination" means.
It is a parsetime error, not a runtime error. If, after parsing, there are still whitespace characters left but they don't make up a whole instruction, or there is nothing in the code input to produce even one instruction, what do you suppose should happen?
I've created a Rust translation.
And thanks to the amazing help from the CodeWars team, this includes a full test suite with all the Elder Master reactions.
Normally, Rust test suite output is pretty bland (no logging, no free-text test descriptions), and tests are run concurrently and so test results are listed in whatever order they completed. But this test suite actually bypasses the normal test runner so we can produce the full "spectrum" of Elder Master emotions. :-)
The Rust translation lacks random tests.
Rust kata can use the rnd crate these days, see the Rust language page in the wiki.
ASCII is a codec with 128 characters, from 0x00 through to 0x7F, inclusive. It's a 7-bit standard.
Yet, the Python test at the very least assumes that chr(255) is valid input; that makes the input require an 8-bit codec. It's not ASCII, so I had to assume Latin-1 (ISO 8859-1), which is a superset of ASCII.
Please correct the description.