On Fri, Jul 20, 2018 at 11:03:12AM +0200, Peter O'Connor wrote: > Often when programming I run into a situation where it would be nice to > have "deferred defaults". Here is an example of what I mean: > > def subfunction_1(a=2, b=3, c=4): > return a+b*c > > def subfunction_2(d=5, e=6, f=7): > return d*e+f > > def main_function(a=2, b=3, c=4, d=5, e=6, f=7): > return subfunction_1(a=a, b=b, c=c) + subfunction_2(d=d, e=e, f=f) > > Here you can see that I had to redefine the defaults in the main_function.
Perhaps you mean duplicate, or repeat, or copy. But surely they're not redefined -- then they would have different values. Being able to redefine the defaults in a wrapper function is a feature. Putting aside the terminology, I think this is a minor annoyance: DRY violations when setting default values. > In larger codebases, I find bugs often arise because defaults are defined > in multiple places, and somebody changes them in a lower-level function but > fails to realize that they are still defined differently in a higher > function. Changing function defaults in production code without a period of deprecation and warnings is a no-no. Default values are a part of the function API, and changing the public API of a function without warning is asking for trouble. But during development, there are no such constraints (your only users are your development team) and it is a real nuisance keeping defaults in sync across multiple functions and/or classes. I've raised this issue in the past: https://mail.python.org/pipermail/python-list/2016-September/714546.html and I still don't have a great solution for it. > The only way I currently see to achieve this is not very nice at all, and > completely obfuscates the signature of the function: [...] There are lots of other ways to solve this. None of which are great. > What I was thinking was a "deferred" builtin that would just allow a lower > function to define the value (and raise an exception if anyone tried to use > it before it was defined) [...] > I assume this has been discussed before somewhere, but couldn't find > anything on it, so please feel free to point me towards any previous > discussion on the topic. https://mail.python.org/pipermail/python-ideas/2011-July/010678.html -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/