On Thu, 23 Apr 2020 14:47:48 -0400
Kyle Lahnakoski <klahnako...@mozilla.com> wrote:
>
> On 2020-04-19 07:23, Richard Damon wrote:
> > There is also the issue that if we are building a function that might be
> > used with another function, we will have an incentive to name our
> > keyword parameters that there is a reasonable chance would also be
> > passed to that other function with the same keyword name, even if that
> > might not be the most descriptive name.
>
> Many of the function keyword parameters I deal with are data property
> names; so it makes sense that the data has the same name throughout the
> codebase. The incentive to align our variable names would be a good
> thing. Consider pymysql, and the connect parameters
>
> > connect(
> > host=host,
> > port=port,
> > user=username,
> > passwd=password
> > )
>
> With the proposal, right, or wrong, there would be an incentive for me
> to write the caller to use pymysql property names, and the callers of
> that caller to also use the same property names. This will spread until
> the application has a standard name for username and password: There is
> less guessing about the property names. I have done this in ES6 code,
> and it looks nice.
(We'll assume, for the sake of discussion, that you meant either (a) to
use the same name for user and username and for passwd and password, or
(2) to use host and port in your explanatory paragraph. IMO, either
way, you're disproving your own point.)
> Maybe aligning variable names with function keyword parameteres is an
> anti-pattern, but I have not seen it.
Sure, that works great. Until you decide to change from pymysql to
pywhizbangdb, and its connect function looks like this:
connect(uri, user_id, password)
Yes, there will be "layers," or "functional blocks," or whatever your
architectural units might be called this week, inside of which it may
make sense to have a unified name for certain properties. But the whole
application? That sounds like a recipe for future inflexibility.
--
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
_______________________________________________
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/MQUI7WE75X66PIZHGEAAKFBLDDM5XSOY/
Code of Conduct: http://python.org/psf/codeofconduct/
