Ezio Melotti added the comment: Without patch: $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et()' 1000000 loops, best of 3: 0.672 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(4)' 1000000 loops, best of 3: 0.744 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(8)' 1000000 loops, best of 3: 0.762 usec per loop
$ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et()' 1000000 loops, best of 3: 0.658 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(4)' 1000000 loops, best of 3: 0.73 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(8)' 1000000 loops, best of 3: 0.769 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(tabsize=4)' 1000000 loops, best of 3: 1.84 usec per loop $ ./python -m timeit -s 'et = "a\tb\tc\td\te".expandtabs' 'et(tabsize=8)' 1000000 loops, best of 3: 1.89 usec per loop If "tabsize" is not used the performances seem the same, if it's used it's 2-3 times slower. I don't think expandtabs is used in performance-critical paths, but if it is the patch shouldn't affect it as long as people don't add "tabsize" to the call. FTR the reason to add this is consistency (Python functions allow you to pass positional args as keywords too) and readability (s.expandtabs(3) might be read as "expand at most 3 tabs" or something else). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17806> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
