On 2021-10-31 15:08, Chris Angelico wrote:
On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D.
<david.me...@gmail.com> wrote:
I am not on the SC, so indeed I won't make the decision. But I
*will* continue to teach Python. New syntax adds a burden to
learners, and it should not be introduced without sufficient
benefit to merit that burden. This proposal does not come close to
that threshold.
How do you currently teach about mutable argument defaults? With
this proposal, it will become trivially easy to have an argument
default that's evaluated fresh every time. Does that not count as
beneficial?
This is a good question. When I've taught Python, I teach about
mutable argument defaults by building on what's been taught about
mutable objects in general. As we know, there are many things about
mutable objects that can confuse newbies (or even people with some
experience), and many of them have nothing to do with default arguments.
For instance, people are sometimes surprised if they do
x = [1, 2, 3]
some_function(x)
. . . and then find that x has changed in the calling environment
because `some_function` mutated it. Or sometimes they're surprised
"from the inside" because they're the one writing `some_function` and
they mutate the argument and didn't realize that could disrupt other
code that calls their function. And so on.
Once people understand the general need to be careful about mutable
objects and where they're mutated, using them as object defaults is not
really a huge additional obstacle. Basically you just have to make
clear that defaults are evaluated only once, when they write the
function, and not again and again each time it is called. If people
understand that, they will basically understand mutable argument
defaults, because that is essentially the same situation in the example
above, and various other cases. It just means "be careful when you
mutate a mutable object someone else might be using that object too".
Of course, they will forget this and make mistakes. So having
late-bound defaults would be a bit of a help. But my point is that many
of the problems learners have with mutable default arguments are really
problems with mutable objects in general, and having late-bound defaults
won't help with those more general confusions.
So the situation is the same as before: yes, there will be a bit of a
benefit, but the benefit is limited. Also, from a teaching perspective,
there is an important cost as well, which is that you have to teach
students about the new syntax and how it differs from early-bound
defaults, and students have to develop the skill of reading function
signatures that are now (potentially) more complex than they were before.
Based on my own (admittedly limited) experience I'm not sure if
late-bound defaults would be a net win in terms of teaching ease. Right
now the situation is actually not too crazy to explain because the
handling of mutable defaults (i.e., the "if arg is None" stuff) goes
into the function body and can be described as part of other general
"prep work" that functions may need to do at the beginning (like, say,
converting inputs to lowercase or doing some sanity checks on
arguments). But the new proposal is something that would actually have
to be learned as a separate thing because of its in-between nature
(i.e., now the argument list becomes a mix of things, some of which
execute in the defining context and some in the calling context).
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/OVITAFAFL3ZELX4CRNERKBCPQGE3S4JY/
Code of Conduct: http://python.org/psf/codeofconduct/
