added to JS

a very nice construction

Pretty much the same:)

judging by the bottom of the Discourse, I think this suggestion was due to the Unicode issues that Codewars had in its early days, and is now stale

It doesn't make sense, you're right. No idea how I ended up with this...

Can you explain why in this line:

c = neighbors.size() == 1 ? EXCHANGE.getOrDefault(wiz+vict, EXCHANGE.getOrDefault(wiz+vict, vict)) : vict;

you call 2 EXCHANGE? I tried leave only second and it works. Thank you for your solution!

https://www.codewars.com/kumite/55caa6025d302a4b9a00005b?sel=569301f1f6629ec51900000a

If you still think this should happen, can you retire it? Else set this issue to resolved please.

reusable

'Missed that word, actually.

The description intentionally specifies "reusable iterable", not "single use iterator".

An iterable can encode a string, so for finite strings they are necessarily functionally equivalent. Iterables do not allow O(1) indexing, and they can encode infinite strings. I don't think they're more different than that, functionally. They have massively different performance characteristics ofc.

These things are the same in all three languages. Or at least they're intended to be. Iterables and iterators can be an intricate subject.

Tests that somehow break the specs should not be added, no.

Does this answer your questions?

Not at all, actually. And spoiler flag, please (done).

Reading the description I'd also expect inputs as iterators (finite ones, not only infinite ones). Tho the finite inputs are all... a random custom handmade type equivalent to simple strings (hence, iterables instead of iterators).
If the input could be a finite iterator, most solutions would not pass the tests (ex: testing both iter("md") and iter("dm"))

• How is it in other languages?
• Should these tests be added, or the description updated to clarify this? (might depend on the language)

EDIT: After digging a bit more in python internals, they actually don't make the difference between Iterable and iterator on the "implementation side", despite iter(x) behaving differently from x (I mean: with some weird objects (not strings) both may be instances of Iterable and Iterator). Which is a bit annoying for the description of the task... :/

BTW:

I do not agree that the description needs info on hashable properties. You do not need to use them, but you may if you want to. They are not part of the spec.

The objects you use are all hashable, while they may not be, depending on the way they are implemented (a class extending list without __hash__ is still unhashable). So if it is possible to use sets/dicts, that still needs to be specified in the description (even only stating that "objects will all be hashable, if you need it" or something like that).

I looked at those tests. They are a bit edgy, for python... you should add those in the example tests, imo. And the description needs a clear spec about what/how you'll test that.