Exercise test cases are now fixed.

OK, show me where in PEP8 it says not to initialize variables, and I'll remove it.

I understand that you are trying to teach your students a particular pseudocode (although the specific pseudocode feels like an extremely poor fit with Python) and how that pseudocode can be mapped to Python. Codewars is not a homework site, however, and katas that actively teach bad coding practice are a bad fit.

That's particularly true for a language like Python, which has such strong culture around best practices. PEP8, anyone?

Yes, that won't help you with floating point numbers. However, there are some (mathematical) functions for (floating point) numbers that relieve you from using * and /.

Could you show how you solved it for integers? That could show whether you have the right idea. Keep in mind that the student will probably have only access on other mathematical functions on his calculator.

I do appreciate the feedback, and I agree that it's weird to have code like:

a = 0

a = 5

but the purpose of the kata is to teach the Gaddis pseudocode standard and how it can be translated into Python, and I can't think of a better way to represent Declare Integer a in Python than a = 0.

This comment appears near the top of the code:

#    Comment: these lines aren't required in Python, but they match
#    Comment: the Declare statements in the pseudocode above, and
#    Comment: help to indicate that these variables will all hold
#    Comment: Real values.

width = 0.0
height = 0.0
area = 0.0

I agree that it's not idiomatic Python to include them, but I think they're useful in an introductory software design course for a few reasons:

1. They serve as documentation for the expected types of the variables as translated from Gaddis-style pseudocode.
2. They get students used to thinking about/understanding data types, which will be important when they learn strongly-typed languages.
3. Explicit variable declarations are required for local variables even in some weakly-typed languages like JavaScript. This is good practice.
4. They can serve to initialize variables that might otherwise remain uninitialized. For example, a = int(input("type a number: ")) will leave a uninitialized if int throws a ValueError due to the user entering a non-numeric value. By providing an explicit initialization line a = 0 this problem is avoided. Similarly with a = b / c where c might be equal to 0.

For those reasons, I prefer to leave them in the example code, though they are by no means necessary for successfully completing the kata. I suggest that if you don't like them in your code as a stylistic matter, that you remove them.

Okay, I think have fixed it! Could you please let me know if it meets your expectations now?

thanks for your suggestion! Do you know a way to block it? I am relatively new and I have not found a way to do this yet...

Well, I've followed your suggestion and added more comments to the kata details. Thanks for insisting - the more I think about it, the more I'm sure these comments are necessary.

I've also improved the tests to make them more generic and (pseudo) natural (and yes, a bit more complex), to prevent guess-and-hope solutions from working.
What we really need here is a stable solution providing reliable decoding (up to a certain degree of operator incaccuracy, of course).

Ok, I see what you mean. Let's make a few things clear.

First, in real messages the rate may not be an integer - while you receive a transmission as a digital message, the line is definitely analogue. For example, you may sample line 10 times per second (100ms per sample), while the operator transmits so that his dots and pauses are 110-170ms long. Clearly 10 samples per second is enough resolution for this speed (meaning, each dot and pause is reflected in the output, nothing is missed), and dots would be reflected as 1 or 11, but if you try to estimate rate (bits per dot), it would not be 1 or 2, it would be about (110 + 170) / 2 / 100 = 1.4. Your algorithm should deal with situations like this well.

Second, each message is a separate message. In one message that seems to have a rate close to 2 (in fact, a bit more), 1111 may mean a very long dot, while in other message, that also has a rate close to 2 (in fact, a bit less), 1111 may mean a very short dash.

Third, for this kata, 1's and 0's are treated equally (and the original solution treats them equally), meaning that in the same message, if 1111 is a dot and 11111 is a dash, than 0000 is definitely an in-character pause, and 00000 is definitely a between-characters pause. If that's not the case for some test, please point it out (well, really it shoudn't be so - if it were, the original solution would fail on that test).

Fourth, "short" test for this kata are syntetic, meaning they were each created manually to test the solution on exteme cases. But the "long" tests were created automatically, by applying a Gaussian noise to length of the fragments, and the amount of noise was adjusted so that the original solution was able to decode it. No special hacks were added to the solutuion to fit those long tests. In fact, the LONGER the message, the EASIER it should be to decode, as you have more information on how dot and dash look like in that particular message. All the real troubles and edge cases occur on very short messages, where information is scarce.

I hope this helps. :)

And by the way, congratulations on solving the kata! You're one of the first to do that, and this task is definitely not an easy one!

Hmm, could you please provide an example of such a message? There could be, of course, a mistake in a test.

Generally I was thinking about what a real-life human-operated transmission could look like; and about how would a human, looking at the received message on a telegraph tape, decode it. To make simple very short tests possible, I made an additional (not so realistic) assumption that if you can't tell whether it's a dot or a dash - assume it's a dot. Besides this assumption, the idea behind this kata is "if it's relatively short - it's a dot, if it's relatively long - it's a dash, if it's much longer and consists of zero - it's an inter-word space".

Seems like this was fixed by Katzen_gott but not merged yet :( https://github.com/Codewars/code-grouper/pull/2

It looks like the java grouping is also causing solutions to not be grouped because of comments...

Good idea, except if the language differs between characters and strings (e.g. Java, Haskell, C, C++, …). However, if the code really just uses other quotation marks, it should be the same (although not compiling anymore in Java, Haskell, …).