The original design of this kata was in Ruby. That design maybe hasn't translated to other languages as cleanly. I don't know Python so I can't really say if the translation used could have been done better, but for this kata having slight variations in the design per language probably is necessary.

I agree that this is an issue. Yes Python is cool and can return multiple data types, but this isn't a case where you would need to return multiple data types as a good example. Its just being done so that the kata has some more personality.

Which is cool to have personality, but many users on this site are learning and its best to not confuse them into thinking this sort of function design is good practice.

Two options to fix:

1. Return -1 instead of the string
2. Leave the string as is, but update the comments to include a tip that this kata is for fun, and it shows how python can return multiple data types, but that its actually not a good idea to return multiple data types from the same method. This way learners actually get a bit of of a mini-lesson.

And yes other kata have this issue, that needs to be fixed.

Basic manipulation of numbers is not a novel idea

This statement could be assumed to mean "all math equations are manipulation of numbers, therefore we only need a few different math equations on this site". No?

I'm not sure if this exact equation has been done on the site before, but unless it has in this exact configuration with a similar problem setup, I don't see this as an issue.

Leaving a note for JavaScript learners. Its good to know about extending native types using prototypes, but extending strings like this is generally considered bad design. In a production application it would be better to have something like

export function isUpperCase(str) {
  ...
}

instead of String.prototype.isUpperCase = function(){...}

Missing a working sample test

x = is not necessary

Interesting, I didn't realize this was becoming a new standard. The amount of times I've had to reject a translation because someone didn't realize they need to keep the existing examples had me programmed to reject as soon as I saw the deleted code.

I guess this is fine, its not my preference but I get how annoying it is for the community in general to manage description diff issues. I've managed my fair share in the past.

I unfortunately can't un-reject, but if you fork a new version I'll approve that.

I need to reject since the instructions are not updated correctly. You should not delete all examples that are there, you should append the cobol example to the list.

Thanks. Rejecting this version since there is only one test cases. Needs multiple test cases, including some random. You can fork and resubmit.

Thanks for the translation!

(is (= (populate-dict [1 2 3 4] "OK")          {1 "OK" 2 "OK" 3 "OK" 4 "OK"})))

does not seem to fit the original challenge design (numbers as keys, strins as values). Why was this test added?

Thank you for your effort on this. This is interesting, I can't say though that it fits the spirit of the kata. Its basically just selecting from a table - also without special instruction for SQL, its probably going to be hard to figure out what is expected since this is really meant as a logic challenge, not a query one.

I'm going to reject this version as I don't think it fits well, but if you have ideas on how to bring it closer inline with the other languages, than you can fork and give it a shot.

Thanks! Please provide more test cases though, some of the older version lack comprensive tests - but languages like Python show an example of more comprehensive testing.

Thanks for the translation. Please add javascript and haskell examples back in. You are not supposed to delete these

If the Kata author requires the RomanHelper to be a class, s/he should really provide a template.

Why? For a 4 kyu challenge one would think you should be able to add a class on your own.

Removed the language for now