
On Sun, Oct 31, 2021 at 09:20:32PM +0100, Sven R. Kunze wrote:
People on the threads said that they simply want to initialize an empty list [] by a desire to avoid the None scheme.
I would rather solve those kind of issues than help to squeeze complicated logic into default parameters. But that's just my take on it looking from testing and maintenance perspective here.
Sorry Sven, I'm not sure I understand you. Are you suggesting that it is simpler and easier to create a whole new execution model for Python, involving a general mechanism for delayed evaluation of expressions, to solve the mutable list default problem, than to merely add late-bound defaults to functions? What sort of testing and maintenance perspective are you referring to? Testing and maintenance of the Python interpreter? Or your own code? If it is your own code then this proposal will have no effect on your testing and maintenance. You already have tests, don't you? Then they will work the same way whether your functions use late-bound defaults or not. If you don't have tests, then the tests that you don't have will continue to not work the same as they currently don't work. Whether your functions use the proposed new late bound defaults, or the legacy work-around pseudo-late bound defaults using a sentinel, is a matter of your functions' internal implementation. It's not something that you should write a doctest or unittest or regression test for: def test_late_bound_default_is_used(self): # Test that late-binding is used for defaults. ... Pedantry: you may be able to test for it using introspection on the function object, but *why* would you do it??? The choice between the legacy "check for None" idiom and the proposed new late-binding idiom is an implementation detail. (Except for the case that your API intentionally documents that None is usable as an argument, in which case, simply change nothing and your code will continue to work as it does today. Including your tests that None is actually usable as an argument.)
Another idea that comes to my mind is that a separate object allows more in terms of the open-closed principle than a fixed syntax used for one single, hopefully best use-case. Thinking here of the call-by-name and call-by-need evaluation.
Call-by-name and call-by-need are, as far as I can tell, specific implementations with no intentional behaviour differences that are visible to the caller. Unlike call-by-value and call-by-reference, which do have intentional behaviour differences. Call-by-value makes copies of your arguments; call-by-reference allows you to modify variables in the caller's scope. -- Steve