Raymond Hettinger added the comment: Perhaps a time-elapsed context manager would be a better fit in the contextlib module (which contains more general purpose macro-level tools usable for many different tasks) rather than the timeit module (which is more narrowly tailored to high-quality reproducable in-vitro performance analysis at a fine-grained level).
> It's a very common task. That said, the task is sometimes solved in different ways. Hard-wiring this to "print" would preclude its use in cases where you want to save the result to a variable, log it, or build some cumulative total-time statistics. Also, I think it ignores some of the realities about how difficult it is to do meaningful performance analysis. The "cumsum" example isn't the norm. Most code is harder to time and doesn't have a high-volume tight-loop that you can that you can easily wrap a course-grained context manager around. Getting reproduceable timings (creating a consistent setup, using repeated calls to average-out noise, and isolating the part you want to test) can be tricky in the middle of real applications. I occasionally have code where the proposed content manager would have been nice (saving me from typing the usual start=time() ... end=time()-start pairs). However, most of the time this technique is too simple and something like Robert Kern's line-profiler or cProfile are a better fit for identifying hotspots. ---------- nosy: +ncoghlan _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19495> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
