Approved

I like option 3 best. As for ejini's points:

• I don't think that it is necessary to enforce the lambdas. The kata is more a "tutorial" style kata, since the solution setup already has them, they do not really add any difficulty, so if someone decides to solve it with normal functions that should also be fine (since the principle is the same anyway)
• I agree that the open / close thing could use some examples explaining how this matches the principle. Not sure what that would look like though
• spoken as used here is fine I think. When something is spoken as opposed to whispered or shouted it talking normally, at normal volume. It does match with a capitalized sentence, since that is regular english grammar.
• Since it deals with functions as objects, lambdas, and the open/closed concept itself is not entirely basic, I think it is a hard 7 or an easy 6, so I don't think its wrongly rated enough to warrant a change.

I prefer all methods other than the 2nd one, with a compulsory update on the description to make things clear ! I'm on the stance of invalidating solutions instead of keeping ones which are probably biased due to incompleteness of description. Also should've mentioned whether ASCII letters only are involved.

BTW I just realized the kata has other flaws -->

• Not enforcing the use of lambda (In Python)

• Not explaining the open / close mechanism precisely with relevant examples

• The usage of spoken as a function name has nothing to do with the output. It neither represents a capitalized word / sentence / text nor it is complied with the language speaking style in English!

• Too easy to be ranked 6kyu and perhaps a combination of many other katas

I might raise a discussion in Discord / Github on what to do with the kata if I have the time later.

This is troubling when I tried to make a random test for it.

For the spoken function, the description & tests are not exactly clear on whether to use str.title, str.capitalize, or do nothing for messages with more than 1 word (You only get to reverse engineer it's behaviour with a single, capitalized word). Choosing any option would have invalidated user solutions using the other approach.

I thought of three ways of overcoming this problem:

1. Like the above translation, always uses 1 capitalized word so str.title, str.capitalize & doing nothing would've achieved the same thing
2. Have multiple solutions for the spoken function and check whether the resultant message matches any of them
3. Use the author's solution approach & improve description to use multiple words (eg, "hello world" => "Hello world.") so user know what to expect, allowing the invalidation.

Why is spoken generated differently than other cases??

Description does not mention how to generate them though, or are you following the examples purely given in fixed tests?

Approved!

Approved.

right, but for something like this, the diff has not much chances to be useful ;)

uhh, just in case you want to compare the diff... but noted, will directly edit on the original translation next time

better to edit the current translation rather than to fork it ;)

good call, forked

plz, replace the string concatenations with str.join, in the random generator

Python fork

• Fixed test framework setup
• Added assertion message
• Language agnostic description change

Python fork

• Fixed test framework setup
• Added assertion message
• Added random tests

Python fork

• Fixed test framework setup
• Added assertion message