Done.

In SQL we have to guess column name in the original table.

No, just running the default code, you see the column names.

It would be better to keep the original name ("time"), as in Python for example.

Changing that now would render all SQL solutions invalid.

So, adding a comment about the column names or adding an specific code block in tha kata description is the best we can do I guess.

Hey sperry, thanks for the kind words!

I added (less than) to the description to clarify what I had in mind. It was intended to be "<" and I put that in my solution. I'm afraid it could be hard to check when it comes to time and Codewars, as the result may vary, and so on. :)

I also added "Dates/Time" tag.

Cheers!

suggestion marked resolved

Well, actually - as you have done - it is also possible to do it without regexp.
By the way, your solutions would fail if a line of length 80 appeared before the real longest line (with e.g. 100 chars).
I'm thinking about to add such a testcase :P) but currently I'm too busy with regular work..

Great! Well done.
I hope that second example finally makes it clear already in the description.

The quotes has nothing to do with this.

Maybe I should give one more example there.
So, you input a big string. First identify the length of the longest line, and call it max_width.

In the written example, we have max_width=80, however in the final test case, the longest line is longer, hence if a line is only 80 characters long, it needs not be concatenated to the next.

Yes, everything as expected. Reconsider the following section of the description:

Also, take care of broken lines. First identify the length of the longest line, and if it is above the default 80 characters, take this as max_width. Then, concatenate each line of length max_width to the next line.

The problem was rather that copying the test input (a real python terminal output) and applying my solution just didn't give the desired result. I will correct the input.

Hmm.. I think you found a bug in my test.. That >>> should indeed be there for the next command.
The problem is that copy-paste from the windows terminal stripped the trailing spaces from each line, and thus the command starter >>>_ (with space) is not matched. After >>> b=(), an empty command was issued which appears as >>> (stripped) in the output.

Actually, however the last test was the real use case that made me write this kata:)
I will correct this part for now and replace it with smaller parts later.
Thanks for the observation, you can also mark it as an issue.

Well, actually, what you wrote first:
">>> print 'answer is\n... tricky\n...'\nanswer is\n... tricky\n...\n>>> if 0: print 42\n"
is almost the same as what I wrote starting with r"""\ but missing the very last line ....
(Note that r before the string interprets it as a raw string, i.e. takes all backslashes literally.)

Have you tried what happens in the python terminal (python from command line)?

If a line contains a colon :, the interpreter will assume that there will be a next line for finishing the command -- hence the expected ... in the end line.

Anyway, the testcase was

log = r"""\
>>> print 'answer is\n... tricky\n...'
answer is
... tricky
...
>>> if 0: print 42
...
"""
test.assert_equals( parse_terminal_output(log),
     [(r"print 'answer is\n... tricky\n...'", 'answer is\n... tricky\n...'),
      ('if 0: print 42', '')] )

Trailing Comma:
For single-element tuple, it's mandatory; for multi-element tuple, it's optional.
For list/dict/args, adding trailing comma is a matter of style... and I think it's encouraged to do so.

(1,) # single-element tuple must have trailing comma
(1) # not-a-tuple, a integer instead, () as precedence operator

Much less easier than expected, but I managed to have it run into P3 too :)