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)

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.

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.

I used Formatter because that's what I used to solve this Kata, avoiding using the name Format as required by the Kata!

I then promptly forgot I had done that. But you are right, it's better, and reduces chances things clash. I've created a fork with that change. I also moved the b/c code to module level, out of the functions. I think I was being overly cautious there.

The class-level attribute stays tags, however. 25 years of code wrangling makes me set in my ways like that. ;-)

There, I've created a revision that removes my [-1000, 1000) range addition, but left in the non-positive -> negative correction. Would that be acceptable?

That could be an issue; for Rust (and C++, C, Java, etc.) you really need to know how big the values can get. I'm happy to remove it if you insist, but then be prepared to field questions about how big the numbers can get. :-)

Then again, I think I overestimated the size of the issue; even an n=100 and i32 numbers you only need 39 bits, tops.

The phrase 'non-positive' is definitely incorrect English, by the way ;-)

Yup, I'm aware this is just a 5 kyu challenge. I do look at Kata test suites and reference implementations as teaching moments, however. Trainees want to see how it "should" be solved, hence my feedback on it. :-)

Looking forward to more such challenges!

And I'm sure you are already aware of the Advent of Code; their 2017 day 11 puzzle was my intro to the subject.