I believe rules about pinging are in the code of conduct. Ping them to bring them into the discussion or to reply if you’re not quoting, but not to remind them or if they said they wouldn’t comment further on the matter.
Also, could you fix the formatting of the example? Thanks.
Yoav: before reading your post, I caught up to it and realized:
What people really want is to be able to interactively get the entire CLI result, not just the warning. Part of the rationale to me is that two of the arguments can be multi-line source code, and these are much easier to work with in a proper IDE such as IDLE, where one has variables and statement editing. This is where I use timeit.
One can currently do this by calling timeit.main with a simulated sys.argv[1:] list of strings.
But this is awkward.
3. timeit.main can pretty cleanly be split into sections that first parse the list of strings into the values needed and then use those values; the latter could then be moved into a callable function.
Your draft is close to what I imagined, except that I think the CLI behavior should remain as is and the run behavior the equivalent but with input adjustments. So I think everything from t = Timer... to the end should be moved into the new function and replaced with return run(...). verbose should be kept as an int, with a revised precision calculation. The unit error checking has to be moved. Make parameters after setup, and maybe that too, keyword only.
I think there is enough support here for a tracker issue: “Make CLI function available from python”, with summary of thread and explanation that aimed at interactive use. Then submit revised PR after making sure it passes test_timeit.
FWIW: I have stopped using timeit in favor of pyperf, which provides much better tooling to measure runtime performance, similar to the old pybench I had written more than a decade ago.