I don't know if the test cases contain such an input, but why not?

+-+
| |
+-+
+-+
| |
+-+
+-------+
|       |
| +---+ |
| |   | |
| +---+ |
|       |
+-------+

Other Jacob/Nathan: Email me directly if you didn't get my response via the Feedback feature regarding this.

We display kata output within a sandboxed iframe on a separate sub-domain. We shouldn't be any more vulnerable than say codepen or jsfiddle. We followed many of the same security practices that they did (that we are aware of at least). We do sanitize markdown output.

If you find any vulnarabilities please let us know and we will get it taken care of ASAP.

Kata do need manual approval by Jake so nothing should survive into approved kata, but beta kata remain vulnerable to this.

This was raised earlier and, understandably, there is some interest in allowing SOME javascript to allow kata authors to do creative things with the output tab but this definitely needs to be balanced against security ASAP.

well that's odd , it does for me O.o

Can you describe the with statement scenario? Also, isn't freezing equivalent to returning original state before/after a potential modification? If that's the with statement scenario, I don't see how that goes against what it was meant to do. The concept is generalizable.

I think I see what you're driving at - the inject method has to explicitly pass the hash along to the next iteration, while the each_with_object method does that for us. But I think I'd hesitate to call one less crufty than the other; each_with_object doesn't need a second statement in the block, but inject seems to keep the variables in a more straightforward order and is a few characters shorter. I ran benchmarks but they compare very closely for speed.

After looking at it, I'd say that the two solutions are pretty much equivalent and I don't see a strong case to favor one over the other. Is there a point I've failed to consider?

Good point, I changed the wording to:

The last address will always be equal to or at least one address higher than the first one.

Oh, I see. For sandboxing purposes and the only real concern we have is preventing access to the Test object; Python does not have built-in object freezing. It was suggested as a PEP but rejected. There exist implementations of it but I haven't looked into them.

That works if you're doing it on your own computer, but here we'd be running it on a sandboxed server and I can't guarantee it'd work. Trying to mess with builtins within python doesn't do anything because you're still coding it in Python; our limitations are due to the language. There is no way to implement anonymous functions whatsoever, and that is what limits the test framework from working the same way.

The current obstacle is running it as a sandbox. There is a test framework in the making, but there's a few issues:

1. Python does not have anonymous functions, so we can't do the same kind of block structure we have been doing for JS/CoffeeScript/Ruby.
2. Python does scoping differently, so even if we implement a sort of "blocking" deal like we have in the other three languages, the scopes don't really work out so well. The only way to do so is with with statements, but that is blatantly against what those statements are meant for, so it's unpleasant to go that route.
3. The only other possibility with the test framework is using decorators, but it looks a little awkward.