[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: > ``if number is None or number < 0`` Sorry, that should be number == 0 -- ___ Python tracker ___

[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: Sorry for the late reply. > 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

[issue36461] timeit: Additional changes for autorange

Michele Angrisano added the comment: I agree with *target_time*. I'm working on it and soon I'm going to update the pr. -- nosy: +mangrisano ___ Python tracker ___

[issue36461] timeit: Additional changes for autorange

Alessandro Cucci added the comment: Thanks Steven, I like the new name "target_time". 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? I'll

[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: 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

[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: 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()`` or ``Timer.repeat()`` to specify a custom target time, is that right?

[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: (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

[issue36461] timeit: Additional changes for autorange

Steven D'Aprano added the comment: > @steven.daprano, would you be able to review the pull requests based > on your original concept for this change? Thank you! With difficulty... for technology/financial reasons, I don't have a browser that works properly with github. But I'll do what I

[issue36461] timeit: Additional changes for autorange

Cheryl Sabella added the comment: @steven.daprano, would you be able to review the pull requests based on your original concept for this change? Thank you! -- assignee: Mariatta -> nosy: -Mariatta ___ Python tracker

[issue36461] timeit: Additional changes for autorange

Change by Alessandro Cucci : -- pull_requests: +12880 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36461] timeit: Additional changes for autorange

Change by Michele Angrisano : -- keywords: +patch pull_requests: +12879 stage: needs patch -> patch review ___ Python tracker ___

[issue36461] timeit: Additional changes for autorange

Alessandro Cucci added the comment: Hello @Mariatta, if this is simple I would like to work on that, can I? Thanks! -- nosy: +Alessandro Cucci ___ Python tracker ___

[issue36461] timeit: Additional changes for autorange

Change by Cheryl Sabella : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36461] timeit: Additional changes for autorange

Cheryl Sabella added the comment: Assigning to @Mariatta for the sprints. -- assignee: -> Mariatta nosy: +Mariatta ___ Python tracker ___

[issue36461] timeit: Additional changes for autorange

New submission from Cheryl Sabella : #6422 implemented the autorange function for timeit, but in msg272704, Steven D'Aprano outlined follow-up change requests to that patch. - make the 0.2s time configurable; - have `timeit` and `repeat` methods (and functions) fall back on `autorange` if