Terry J. Reedy <[email protected]> added the comment:
Thanks for the report, which I verified on 3.2.2, Win7. When reporting a bug,
please give a minimal example of code showing the bug, and the buggy output. I
presume you mean something like the following (slightly edited):
>>> profile.run('for i in range(10): len({})')
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.000 0.000 :0(exec)
10 0.000 0.000 0.000 0.000 :0(len)
1 0.016 0.016 0.016 0.016 :0(setprofile)
1 0.000 0.000 0.000 0.000 <string>:1(<module>)
1 0.000 0.000 0.016 0.016 profile:0(for i in range(10):
len({}))
0 0.000 0.000 profile:0(profiler)
>>> profile.run('for i in range(10): range(1)')
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.000 0.000 :0(exec)
1 0.000 0.000 0.000 0.000 :0(setprofile)
1 0.000 0.000 0.000 0.000 <string>:1(<module>)
1 0.000 0.000 0.000 0.000 profile:0(for i in range(10):
range(1))
0 0.000 0.000 profile:0(profiler)
The one call to range(10) and in the second case, the 10 calls to range(1) are
missing while in the first case, the 10 calls to len(()) are reported. This
looks like a bug to me. As far as I know, len and range are equal status
builtin functions. The only Limitations reported in the doc are about timing
accuracy.
A minimal test for this would be to look for ":0(range)" in the output, to
match the way ":0(len)" does now.
----------
nosy: +terry.reedy
stage: -> needs patch
versions: +Python 3.3
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue12953>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
