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.

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