You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure about the API for making the time used by autorange configurable. The time taken is only used when autoranging, but the API takes it as an argument to the constructor even if it won't be used. I haven't thought deeply about this for a few years, so now I'm wondering if this is the best API. Let me think some more.
However, the parameter name "max_time_taken" is certainly wrong: it can be wrongly read as meaning the maximum time the sample code will run, which is not the case.
Also, it is not a maximum time, it is a minimum time: the autoranger increases the number of loops until it takes at leastmax_time_taken seconds, not at most.
So I think a better name might be something like target_time. It suggests a time we are targeting, not one we promise to hit precisely, it doesn't mislead into thinking it will be the total time. And it is a bit shorter without being cryptically short.
Anyone have any better suggestions for the parameter name?
Likewise I suggest default_target_time for the global (line 62).
With the longer parameter list, there's a couple of places that the line length seems to exceed 79 columns, e.g. lines 244, 272.
Line 176: I think that should be ``if number == 0:`` since we don't want to accept any arbitrary falsey value, just zero.
The only API for setting the target time is by passing it to the autorange method directly. So I think that there's no way for the caller of Timer.timeit() or Timer.repeat() to specify a custom target time, is that right?
Michele, Alessandro, thank you both for your work! And thank you Cheryl for managing this ticket.
I like mangrisano's design where the target time is passed as an argument to the autorange method, although I prefer the name "target_time". (But I'm open to alternatives.)
So I think a good approach might be a hybrid between mangrisano's design, and the design by Alessandro:
the constructor takes the target time and records it as an attribute;
when the timeit method is used, if number=0 the target time is taken from self.target_time and passed to autorange;
if the autorange method is called directly, the caller can override the target time by passing it as argument; otherwise the default value is looked up from the instance attribute.
Just a question: why we need to check ``if number == 0:``? In the
proposal you asked for None too. What changed? Even if the function is
called with False, will it hurts to keep the default value?
Fair question. On rethinking, I'm okay with an explicit check for None
or zero, if number is None or number < 0 but I don't like the idea
of accepting any falsey value.
Calling the function with False is fine, since False == 0 but I don't
think it is fine to call the function with (say) [] or {} or "", which
are all falsey values.
Activity
csabella commentedon Mar 28, 2019
bpo-6422 implemented the autorange function for timeit, but in msg272704, Steven D'Aprano outlined follow-up change requests to that patch.
timeitandrepeatmethods (and functions) fall backon
autorangeif the number is set to 0 or None.Opening this ticket for those change requests.
csabella commentedon Mar 28, 2019
Assigning to @Mariatta for the sprints.
alessandrocucci commentedon Apr 19, 2019
Hello @Mariatta,
if this is simple I would like to work on that, can I?
Thanks!
csabella commentedon May 24, 2019
@steven.daprano, would you be able to review the pull requests based on your original concept for this change? Thank you!
stevendaprano commentedon May 24, 2019
With difficulty... for technology/financial reasons, I don't have a
browser that works properly with github. But I'll do what I can.
stevendaprano commentedon May 24, 2019
(Sorry, I can't comment on Github.)
Looking at PR 12954:
I'm not sure about the API for making the time used by autorange configurable. The time taken is only used when autoranging, but the API takes it as an argument to the constructor even if it won't be used. I haven't thought deeply about this for a few years, so now I'm wondering if this is the best API. Let me think some more.
However, the parameter name "max_time_taken" is certainly wrong: it can be wrongly read as meaning the maximum time the sample code will run, which is not the case.
Also, it is not a maximum time, it is a minimum time: the autoranger increases the number of loops until it takes at least
max_time_takenseconds, not at most.So I think a better name might be something like
target_time. It suggests a time we are targeting, not one we promise to hit precisely, it doesn't mislead into thinking it will be the total time. And it is a bit shorter without being cryptically short.Anyone have any better suggestions for the parameter name?
Likewise I suggest
default_target_timefor the global (line 62).With the longer parameter list, there's a couple of places that the line length seems to exceed 79 columns, e.g. lines 244, 272.
Line 176: I think that should be ``if number == 0:`` since we don't want to accept any arbitrary falsey value, just zero.
NEWS line 4: take out the reference to None.
(I haven't reviewed the tests at this stage.)
stevendaprano commentedon May 24, 2019
Looking at PR 12953:
The only API for setting the target time is by passing it to the autorange method directly. So I think that there's no way for the caller of
Timer.timeit()orTimer.repeat()to specify a custom target time, is that right?stevendaprano commentedon May 24, 2019
Michele, Alessandro, thank you both for your work! And thank you Cheryl for managing this ticket.
I like mangrisano's design where the target time is passed as an argument to the
autorangemethod, although I prefer the name "target_time". (But I'm open to alternatives.)So I think a good approach might be a hybrid between mangrisano's design, and the design by Alessandro:
timeitmethod is used, if number=0 the target time is taken from self.target_time and passed toautorange;autorangemethod is called directly, the caller can override the target time by passing it as argument; otherwise the default value is looked up from the instance attribute.So something like
Please suggest alternatives or point out anything I may have missed, and thank you all again!
(I'm now going to be away from the keyboard for at least the next 18 hours so if I don't reply quickly, that's why.)
2 remaining items
stevendaprano commentedon Jun 1, 2019
Sorry for the late reply.
Fair question. On rethinking, I'm okay with an explicit check for None
or zero,
if number is None or number < 0but I don't like the ideaof accepting any falsey value.
Calling the function with False is fine, since False == 0 but I don't
think it is fine to call the function with (say) [] or {} or "", which
are all falsey values.
stevendaprano commentedon Jun 1, 2019
Sorry, that should be number == 0
CohenAriel commentedon Aug 13, 2023
It looks like both the PRs have been inactive for four years, so is this still relevant? If so, can I open a new PR?
gabrielfougeron commentedon Dec 29, 2023
Hi @CohenAriel
Did you end up opening a new PR? I'd love to see this 0.2 be configurable.
Cheers
CohenAriel commentedon Dec 30, 2023
gabrielfougeron commentedon Jan 2, 2024
encukou commentedon Mar 19, 2024
CohenAriel commentedon May 2, 2024
miikka commentedon Oct 18, 2025
For whatever it's worth, I opened a new PR based on the old one and tried to get it up to date: #140283
gh-80642: timeit - make target time of autorange configurable (#140283)
pythongh-80642: timeit - make target time of autorange configurable (p…