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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MEWFODIQQVDZ3UC4CJPUXH53D5KI3VJ3/
Code of Conduct: http://python.org/psf/codeofconduct/
