time(it) magic: Implement minutes/hour formatting and "%%time" cell magic

[jankatins]

%%time cell magic and better formatting for longer times (minutes/hours)in both timeit and time magic.

Currently minutes and hours use simple float formatting, not "hours:minutes:seconds" (1.5 min is 1 minute 30 secs).

fixes #2751 (partly)

[minrk]

Just curious: under what circumstances would you use %timeit -o instead of %time?

[jankatins]

I have a network analysis where I put several steps in one cell and then run the whole cell with %%timeit -r1 -n1. I could probably split that or refactor the code into a function, but using cell level timeit was easier. It's also easier to comment out when I don't want to time it anymore.

An example cell (of abut 10 in that notebook, some now commented out):

%%timeit -r1 -n1
eigen = g_giant.eigenvector_centrality()
g_giant.vs["eigen"] = eigen

[jasongrout]

So would it be easier to just have a %%time cell magic?

[jankatins]

If that would do the same as %%timit -r1 -n1: yes...

Oups, now I see why @minrk was asking (one '%'...): yep, for line magics, the %timeit -o is equivalent to %time.

[minrk]

And yes, %%time should absolutely be registered as a cell magic, I've typed it a million times - that should be a one-liner, if you want to add that here.

[minrk]

The only advantage left would be the difference in how %time and %timeit report the time (%timeit shows loops, which are irrelevant for one run, but %time doesn't reformat the times if they are significantly less than one second).

[jankatins]

Ok, so

• Add a new internal function which does the time formatting
• use that in both timeit and time magics
• Make the time magic cell aware

I can do the first two but the last is something I haven't yet an idea how to do it... lets see...

[jankatins]

Hm, that was easier than I thought...

[takluyver]

While we're working on this, it would be nice to get the proper µ prefix again - this comment is ancient. I think that checking u'µ'.encode(sys.stdin.encoding) should be OK.

[jankatins]

It works in a windows command prompt (open cmd, -> ipython)... But in ipythonqt, sys.stdin.encoding is "NoneType"...

[takluyver]

What about sys.stdout.encoding - that's UTF-8 in the terminal and the Qt console for me. Plus it makes more sense to check it for output. There's some reason we look at stdin elsewhere, but I forget what it is.

[jankatins]

I just read https://bugs.launchpad.net/ipython/+bug/348466 And I'm not sure what happens here: if some user has the terminal encoding set to ascii, it will result in an unicode error.

For example eclipse set the default stdout encoding in the embedded console to None but print works...:

>>> import sys
>>> print(sys.stdout.encoding)
None
>>> print(u'µ'.encode(sys.stdout.encoding))
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: encode() argument 1 must be string, not None
>>> print(u'µ')
µ

I think the only "working" solution would be to try to print a "µ" and if hat fails use "u" instead, but I've no idea how to do that without actually printing a char to the console...

[takluyver]

False negatives don't matter much - users in Eclipse will still see 'u'. We
want to avoid false positives, i.e. trying to display µ when we can't do
so. I think using sys.stdout.encoding is an improvement for all the users
where it is set. But if you're not sure, leave it, and we'll do it in a
separate pull request.

On 3 February 2013 12:59, JanSchulz notifications@github.com wrote:

In IPython/core/magics/execution.py:

@@ -1091,3 +1071,43 @@ def parse_breakpoint(text, current_file):
return current_file, int(text)
else:
return text[:colon], int(text[colon+1:])
+
+def _format_time(timespan, precision=3):

• """Formats the timespan in a human readable form"""
• import math

• XXX: Unfortunately the unicode 'micro' symbol can cause problems in

• certain terminals. Until we figure out a robust way of

• auto-detecting if the terminal can deal with it, use plain 'us' for

• microseconds. I am really NOT happy about disabling the proper

• 'micro' prefix, but crashing is worse... If anyone knows what the

• right solution for this is, I'm all ears...

I just read https://bugs.launchpad.net/ipython/+bug/348466 And I'm not
sure what happens here: if some user has the terminal encoding set to
ascii, it will result in an unicode error.

For example eclipse set the default stdout encoding in the embedded
console to None but print works...:

import sys>>> print(sys.stdout.encoding)None>>> print(u'µ'.encode(sys.stdout.encoding))Traceback (most recent call last):
File "", line 1, in TypeError: encode() argument 1 must be string, not None>>> print(u'µ')µ

I think the only "working" solution would be to try to print a "µ" and if
hat fails use "u" instead, but I've no idea how to do that without actually
printing a char to the console...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2855/files#r2870793.

[jankatins]

Another implementation, which does hour:sec formatting: http://snipplr.com/view/5713/

[jankatins]

I've added a commit to print real "µs" instead of "us". Please test as I'm not sure if that won't break on funny terminals...

[minrk]

speaking of funny terminals, Travis apparently uses an ascii locale.

[minrk]

So one more case is when stdout is overridden with a StringIO, in which case it may have no encoding attribute.
This should be taken care of if you use utils.encoding.get_stream_enc(sys.stdout), which catches that sort of thing.

[minrk]

Looks good to me now.

[takluyver]

This works in my tests, so I'll merge it. Thanks!