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
_______________________________________________
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/HAWPJLWS6GFBDMSRDKWQKDTJCEQB6VOZ/
Code of Conduct: http://python.org/psf/codeofconduct/
