I definitely agree with that sentiment, with beginners I don't even talk about function defaults at first, and when I do, it's when we have already have a talk about mutables so I can just say that you almost never want a mutable default but rather use None as a sentinel. It's not that hard and it serves as a reminder of how mutables work, so it's actually good for teaching!
I don't look forward to having to add yet another side note about syntactic sugar that does not really add much value (it saves a few characters but it's less clear and relying on code to document the parameters is a bit meh imo). Because I won't burden beginners who are already having to ingest a lot of thing with a new model of evaluation. I guess an alternative could be to only teach late binding but since all the code written so far is early bound, it's not practical. Cheers, E On Mon, 1 Nov 2021, 01:05 Brendan Barnwell, <brenb...@brenbarn.net> wrote: > 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/ >
_______________________________________________ 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/LIWWG5J75HFGPSMTUP5PMRWB6MEIK5Y4/ Code of Conduct: http://python.org/psf/codeofconduct/
