
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