Chris Angelico writes:
> Except that render_template isn't one of my own functions. It's part
> of the templating engine (this is a Flask web app). There is no
> refactoring to do - that IS the correct way to call it.
So NOW you tell me! ;-) Just kidding: of course I recognized that as a
library call. Of course cases where one calls a library function with
a plethora of keyword arguments and large fraction of them are going
to take same name variables as keyword arguments are going to exist.
The question is are they frequent enough to justify an IMO ugly syntax
change. There are a lot of other factors involved, such as why there
are so many randomly-assorted variables that are nevertheless related
by this function call, whether this particular call is repeated with
the same objects (so that it might be worth wrapping it in a
marshalling function with appropriate defaults), if it would be
conceptually useful to have a library manager object that collects all
of the assorted variables, and so on.
I'm arguing that multiple changes in Python, and additional experience
for me, mean that I run into same name arguments much less frequently
nowadays than I once did, frameworks like Flask notwithstanding.
There are several reasons for that, including:
1. Variable naming that refers to the role in the application, rather
than the role in the function called.
2. Constructs like comprehensions and zip() that make writing helper
functions that call for same name arguments less attractive.
3. Using local rather than global functions in helper roles,
eliminating same name arguments in favor of nonlocal access.
None of those is a panacea; 2 & 3 are completely inapplicable to the
render_template example, and 1 is a matter of style that I think is
becoming widespread in the Python community (at least in the code I
have to read frequently :-) but is certainly your choice, and any
programmer's choice, not mine. And it will vary with the particular
library: if you have to call constructors for a bunch of library
facilities and do nothing with them but pass them to library
functions, the argument names are the obvious variable names. I
recognize that.
But all of them together, including some not mentioned here, have the
effect that this issue is much less salient for me than it used to be,
so I'm a lot less sympathetic to this syntactic sugar than I would
have been five years ago.
I don't know how common this experience is, but I think it's
reasonable to present it, and to suggest that it may be quite common.
Steve
_______________________________________________
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/XEJ766PXPFHLL2NQ7W5ECWXRXLKCVZVV/
Code of Conduct: http://python.org/psf/codeofconduct/
