It does indeed work now. Many thanks.

Some test-cases for the julia translation might be broken:

I need to catch calls to diag_2_symSE and rot_90_counterSE by hand and replace them with my own non-SE functions in oper, otherwise some tests throw an

ERROR: LoadError: LoadError: MethodError: no method matching split(::Array{String,1}, ::String)
...

in those two functions.

Well it did somewhat, but only after submitting.

On further thought I don't think there is really that much difference between this kata and the kata for the next bigger grid size and I actually did not expect this solution to be fast enough. And for the multisize kata this solution does not work (because apparently I've overlooked bugs for non-quadratic grids and because it is still too slow)

Creating the list is still O(N)

In the python tests the number '0' is not neutral as told in the description but counted as even.

It seems weird at first glance, but think about what happens for example in your check for evenness if i is a string.

I don't think that the runtime can be significantly improved. The algorithm is already linear with respect to the size of the input string and unless there are restrictions on the nesting, number of brackets, ... every char needs to be processed.

So the only room for improvement would be to minimize the number of operations needed for each char. As far as I know python lists are optimized for fast append() and pop(), so no possible improvement for the stack. The remaining code seems pretty optimal. Looking at your solution the only 'obvious' improvement (since this is a python2 kata) would be to replace range with xrange, but in my tests range, xrange and enumerate all have a similar runtime. The differences are much smaller than the differences due to the load on the codewars servers. So for compatibility with python3 I would stick with range.

For the first issue, can you try and put the flush before sys.stdout.buffer.... It seems that there are two different buffers for stdout at work here, that have to be flushed in the correct order.

The second issue I don't understand at all. I've seen it during some tests exactly once yesterday and once today, but so far I can't reproduce it. Usually I get the correct unicode symbols.

OK, next try:-)

The following part for python3 seems to be working for me as intended:

sys.stdout.buffer.write(uni_str.encode('utf-8', 'surrogatepass'))
sys.stdout.buffer.write(b"\n")
sys.stdout.flush()

@zebulan,

since the print-statement does that automatically, did you try to add a linebreak ('\n') at the end of each string?