[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