chill out dude. I was just giving some suggestions about a kata that you must have known was lacking a bit. No need to get nasty.

come now, surely this could be little bit more difficult/realistic.

You're askng the user to define a constant for both the gas efficiency of a (single i suppose) car and also for the price of gas! a good constant is pi, the freezing temperature of water etc, something that will never change over the use of the software. The price of petrol has to be one of the worst constants i've ever heard of.

gas efficiency also changes with stop-starts, load etc (and of course from car to car), I would suggest using these factors to make the kata less silly.

While I get that it's supposed to be simple. I think it might need a little more more rigour in order to even pass as a level 8 kata...

here are some questions to could ask yourself to provide slightly better test cases and specification:

• how would you like the solver to respond to null-ish input (such as an empty string)?
• what would happen if the person was actually an integer/float/whatever? Can the solution handle non-strings?
• at the moment all your tests are already nicely formatted single word names. If this was real user input we would never have it so easy! Input would be messed up and you'd probably have some 'names' like [JOSHHHH, blargalarg666, steven h. stevenface, '', '*(@*(@Y@R#%%D%8f'] as well as some unicode challenges (in 2.7 at least).

I'm not saying all these things need to be a covered in the kata but I think if you take some of them into account, and are sure to cover them thoroughly in both the test cases and description you'll have a higher quality kata that is still totally suitable for beginners, but gives them enough of a challenge to make them feel like they've accomplished something.

i made a small correction to the final example test case where the leading zero in datetime(1954,05,16)) was causing a syntax error. It is now datetime(1954,5,16)).

@mmalkavian:

I shouldn't say this as I've authored myself a string reversing kata, but it was still a challenging Shell language kata; so why have I done that? I had to translate it in javascript and python to make it popular with the result that it has become very easy in these 2 languages (and even got some down-votes).

You don't need to justify creating kata's a simple kata. That's fine of course. And yeah it's a shame you felt the need to translate your Shell kata into more crowd pleasing languages ( that likely defeated the difficulty in the original language.)

Personally I have no problem with the abundance of 7 & 8 kyu kata's out there. It's human nature to avoid difficulty and codewars is a quick relaxing activity for a lot of people I guess. And beginners need challenges too (watch me try and solve anything over 7kyu in Haskell... it's not pretty). I just would like to see more hard katas and think it's a shame they never come out of beta.

I agree with some of your points but I don't think the codewars scoring system should become any more complicated.

• I don't think removing points is really the way forward I think generally, would cause a lot of confusion and upset people, who likely just solved a kata in good faith.

• I also disagree with forcing people to author katas, it's weird and not everyone wants to do that. Making someone who doesn't want to author a kata do so will just make a lot more crappy poorly thought out katas.

For me your first point :

give the honor points after solving and ranking;

is the simplest solution. If someone is doing betas and not either ranking or contributing with issues or suggestions they shouldn't get 'special beta points'.

In the meantime maybe we could start a 'Get my level x or above kata out of beta' thread...

re: Python translatation.

I'd reccomend changing def keyword_cipher(string, keyword): to def keyword_cipher(msg, keyword): in initial solution to avoid messy namespace w/ string library. Not a nessessity but would be nice.

fair enough :

@renjia93 , I hereby register my opinion that it's wierd to expect 0 in above case.

just an opinion of course :)

Odd I thought this had been fixed in a fork from last week...

I know a few people have mentioned this already. But it would be great to find a way of encouraging users to solve some of the more difficult beta kata. I personally would like to see more difficult katas on the site and have seen the poor response that difficult katas in beta get. It may also be worth making approval ( or disapproval ) mandatory on completing katas, I'm guilty of not always marking them myself and lots of people complete the kata (with issues or not) and don't rate it.

  it("test3", function(){
    var list = [null, -2];
    Test.assertEquals(getMin(list), 0, "test fails");
  });

why do we expect 0 in this case?

just a couple minor minor corrections + spacing (itertools imported twice, odd brackets in a dict)

also since this kata is not just in JS perhaps the description should be edited as courtesy to users of other languages who may not do console.log...

so:

console.log(checkType("aaa"));
//console : string

would be something like:

checkType("aaa") == string

or

checktype("aaa") ==> string

or whatever...

could use some test cases for other types such as lists, functions maybe?

class SomeClass(object):
    pass

def f():
    pass

some_class_obj = SomeClass()
some_list = [1, 2, 3, 4]
some_tuple = ('a', 'b', 'c')
some_function = f

Hi, Sorry there's a little issue in your description:

Given an array of integers,separate the odd intergers from the odd even ones. Discard the even but keep the odd.

Taequin: this is a translation ascii_letters would not fit the original kata description, which as the above poster mentioned requires that upper and lowercase test cases are not mixed.

Also forker who can not be named: Cheers for python3 compatability fixes. I'm stuck in my ways 2.7 regressive ways and hadn't noticed. Many thanks.