Then if you had a very short message such as "A"(.-) or "I"(..) how can it be possible to discriminate between these two messages, when a . and - can be almost exactly the same length??

Hi, now I see that you didn't get any answer.

(1) listOf(...).map { ... }.joinToString(...)

is equal

(2) listOf(...).joinToString(...) { ... }

Intelij simplifying (1) into (2) automatically.

The option is available in traning setup.

Privacy. It is not relevant to this example, but it would be a good choice if the programmer did not want the sub-function to be scoped outside of the current function.

Yes, in this particular kata it can happen that 5 is a very long dot and 6 is a very short dash.

The part of the description you're quoting as about a different thing.
It says that if somewhere in the message 11111 means a dot, then everywhere in that message where 11111 is encountered, it would mean a dot, and the same is true for any other sequence.
In other words, different number of 1s can mean a dot, but if something is a dot it's a dot, never dash, and vice versa.

That input is for 3 different tests, the first two expect "E" and the last one expects "I", 101 at a slower speed: 110011.

The first case should be "-3--1" instead, so no, no ambiguity.

1. Those aren't variables but extension properties.
2. For the kata it isn't needed, but it's sort of a cleaner practice IMO; the extension properties only make sense for the high function so no need to make it accessible everywhere.
3. There's nothing to indent really, all those definitions are top-level. (Note that it's not a function high with variables inside it.)

Hope that helps :)

It's extremely unpythonic! If I could go back and edit this I would definitely move the import statement to the top of the file. (I submitted this solution a few years ago)

Edit: Also the indentation on that dictionary -- yuck

The downside of having only one type of connections, is that you cannot avoid performiong a scan of all vertices (persons) to find the connection(s) in the other direction. This impacts the time complexity of the algorithm.
Two-way connections are not a problem as long as you only modify them through methods that update both directions at the same time.

@Donald: I suggest the small rewording in bullet point 1.

Reworded as requested.

sure. And you just did learn something, didn't you? ;)

errr.... Nope, I disagree. Sorry but it rather sounds like you're not mastering exception usages, that's all.

1. I don't understand your sentence... Or maybe... Do you mean that a raw raise won't work, for example? Well, I guess the problem is that the original is in JS, where (maybe!) things are a bit different. Maybe changing this to throw/raise an exception (of any kind) could be better, then, yes.
2. what...!? :o Ofc not. On your side, you only need if badCondition: raise Exception(...), period.
3. ofc. That's the very basics of writing code that throws/raises... ;p

@Donald: I suggest the small rewording in bullet point 1.

cheers guys.

that's basically what you should do:

def execute(code):
    raise Exception('error testing')

but you cannot "test" it that way because raising an exception when the tests do not expect one will... well... OFC raise an exception and stop the test suite completely. So raise it, but only when you should, and absolutely not return something when you should raise an exception.

So, "no issue" situation confirmed. ;p