
Kyle Lahnakoski writes:
Maybe aligning variable names with function keyword parameteres is an anti-pattern, but I have not seen it.
I consider this an anti-pattern for my use case. I review a lot of different students' similar code for different applications. They borrow from each other, cargo cult fashion, which I consider a good thing. However, it's only a good thing to a point, because at some high enough level they're doing different things. I want variable names to reflect those differences, pretty much down to the level of the computational algorithms or network protocols. Despite Steven d'Aprano, I also agree with Dan Sommers:
Sure, that works great. Until you decide to change from pymysql to pywhizbangdb, and its connect function looks like this:
The reason I disagree with Steven is that almost certainly pymysql and pywhizbangdb *already have copied the APIs of the libraries they wrap*. So the abbreviated keyword arguments do not go "all the way down", and *never will*, because the underlying libraries aren't implemented in Python. Nor will the implementers be thinking "we should choose the names our callers are using" -- for one thing, at that point there won't be any callers yet! So the coordination can only go so far. Then consider something like Mailman. In Mailman 2, there is no abstract concept of "user". There are email addresses, there are lists, and there is the relation "subscription" between addresses and lists. Mailman 2 APIs frequently use the term "member" to indicate a subscriber (ie, email address), and this is not ambiguous: member = subscriber. In Mailman 3, this simple structure has become unsupportable. We now have concepts of user, who may have multiple email addresses, and role, where users may fulfil multiple roles (subscriber via one of their addresses, moderator, owner) in a list. For reasons I don't know, in Mailman 3 a member is any user associated with a list, who need not be subscribed. (Nonmembers are email addresses that post to the list but do not have proper users associated with them.) This confused me as a Mailman developer, let alone list owners who never thought about these internals until they upgraded. I don't think either definition ("subscriber" vs. "associated user") is "unnatural", but they are different, this is confusing, and yet given the history I don't see how the term "member" can be avoided. So I see situations (such as the proverbial 3-line wrapper) where coordinating names is natural, obvious, and to be encouraged, others where it's impossible (Python wrappers of external libraries), and still others where thinking about names should be encouraged, and it's an antipattern to encourage coordinating them with function arguments by allowing abbreviated actual arguments.