[Python-ideas] keyword arguments everywhere (stdlib) - issue8706
Steven D'Aprano
steve at pearwood.info
Mon Mar 5 00:32:38 CET 2012
Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 7:42 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> I'm still +1 on adding named arguments to built-ins where needed, e.g.
>>
>>>>> "spam".find('a', end=1)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: find() takes no keyword arguments
>>
>> but I hope that would be uncontroversial!
>
> No, because str may be subclassed, so this change would break
> backwards compatibility for subclasses that chose a different name
> instead of 'end'.
I think that's a genuine problem in theory. But is it a problem in practice?
Since find('a', end=1) doesn't currently work, there won't be any code using
it in practice. Even if a subclass looks like this:
class MyString(str):
def find(self, substring, beginning=0, last=None):
...
internally MyString.find must be using positional arguments if it calls
str.find, because keyword arguments don't currently work. So this suggested
change will not break existing code.
I can see one other objection to the change: if str.find accepts keywords, and
MyString.find accepts *different* keywords, that is a violation of the Liskov
Substitution Principle. Those who care about this would feel obliged to fix
their code to match the argument names used by str.find, so if you call that
mismatch "breaking backwards compatibility", I accept that.
[Aside: in my experience, most programmers are unaware of Liskov, and
accidentally or deliberately violate it frequently.]
But given that str.find has been documented as "S.find(sub[, start[, end]])"
forever, I don't have a lot of sympathy for anyone choosing different argument
names. (I'm one of them. I'm sure I've written string subclasses that used s
instead of sub.)
I think that the practical benefit in clarity and readability in being able to
write s.find('a', end=42) instead of s.find('a', 0, 42) outweighs the
theoretical harm, but I will accept that there is a downside.
--
Steven
More information about the Python-ideas
mailing list