The attached patch adds keyword args support to str/bytes.expandtabs():
>>> 'a\tb'.expandtabs(tabsize=8)
'a       b'
>>> b'a\tb'.expandtabs(tabsize=8)
b'a       b'

Where is the “Approve patch” button :)

Note that adding support of keyword arguments significant slowdown argument parsing. Please measure time of the function call with and without the patch.

I object to add support for keyword arguments in a quick built-in functions. Especially if it's the only argument.

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).

> FTR the reason to add this is consistency

This always was a weak reason.

> and readability

It is a matter of taste. For me s.expandtabs(3) looks more readable than s.expandtabs(tabsize=3).

I don't see an urgent need for this feature and don't like a complication. Let's defer this change until the passing of the keyword arguments will not be significantly optimized. I'm -0 for committing right now.

> For me s.expandtabs(3) looks more readable than s.expandtabs(tabsize=3).

I disagree:  I think the second is more readable, and I think it's especially helpful to those not intimately familiar with the language (which probably accounts for the vast majority of Python users) to see code like "s.expandtabs(tabsize=3)", or "int(43, base=8)", or "s.splitlines(keepends=True)":  such code is instantly understandable, whereas someone seeing "s.splitlines(True)" likely has to stop and wonder what the "True" is doing.

Ezio, you can commit the patch if you want.

New changeset 82b58807f481 by Ezio Melotti in branch 'default':
#17806: Added keyword-argument support for "tabsize" to str/bytes.expandtabs().
http://hg.python.org/cpython/rev/82b58807f481