-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
supplying an empty string to timeit causes an IndentationError #84847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The Error can be evidenced below:
|
Is this different than what you would expect? Supplying garbage to timeit will result in an error: >>> from timeit import timeit
>>> timeit('weofinwofinwe')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/timeit.py", line 232, in timeit
return Timer(stmt, setup, timer, globals).timeit(number)
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/timeit.py", line 176, in timeit
timing = self.inner(it, self.timer)
File "<timeit-src>", line 6, in inner
NameError: name 'weofinwofinwe' is not defined If you want to time an empty loop, you can use: >>> timeit('pass', number=10000)
0.0001043230000021822 |
Yes, This is unexpected In the first case: In the second case: In the third case: |
Calling timeit from command-line with the empty string defaults to 'pass'. I suggest to adopt this behaviour for calling timeit.timeit in the REPL as @edison.abahurire already suggested. I would be happy to submit a PR for it. |
Accepting an empty string in CLI is just an artifact of the implementation. There was no intention to support it. It will fail if pass a space:
or two empty arguments: I do not see this is an issue. Garbage in -- garbage out. IndentationError is a subclass of SyntaxError, so if you handle it programmatically, it does not matter. Of course we try to catch some user errors and provide informative traceback. timeit now correctly handles most of code which interferes with the control flow in functions and loops: 'return', 'yield', 'break', 'await'. But it is still possible to bypass the validation. For example:
I think there is an infinite number of ways to fool timeit. And an empty string is just one of them, not special enough to add a special handling in the code. |
I see your point and agree with you. However, IMHO the CLI and the direct function call should behave the same way to not confuse users. The opened PR ensures that. |
Let a wcs be a string consisting of only whitespace and comments. If one thinks of parameter stmt as a top-level statement (or statements), it is reasonable to expect '' to be the same as 'pass'. If one knows that stmt will be embedded into a compound statement (whether 'while', 'for' or 'def' does not matter here) for repeated execution, then 'pass' is more obviously the minimal statement. It would have been better if the parameter name were 'suite', as suites can never be only whitespace. We cannot change this, but I suggest replacing The constructor takes a statement to be timed, an additional statement used for setup, and a timer function. Both statements default to 'pass'; the timer function is platform-dependent (see the module doc string). stmt and setup may also contain multiple statements separated by ; or newlines, as long as they don’t contain multi-line string literals. with the shorter, clearer, and updated The constructor takes suite of statement to be timed, an additional suite used for setup, and a timer function (default time.perf_counter). Both suites default to 'pass' and may not contain multi-line string literals. Since 3.3, the default timer is platform-independent, at least from a user viewpoint, and not mentioned in timeit.__doc__. Suites can always have multiple statments separated by ; and \n. The only needed qualification is the default and the restriction. |
@terry.reedy sorry if I misunderstood you, but it seems to me that you agree with the proposed changes? |
I intended to say that the current behavior would be less puzzling if the doc were changed as I suggest. I think that a doc change would be sufficient. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: