On Sun, Oct 31, 2021, 6:11 PM Chris Angelico
On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D. <david.mertz@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?
I teach folks to use a sentinel. Yes, it is genuinely a thing to learn, but it takes far less mental effort than special syntax and a different evaluation model. At least 99% of the time, the None sentinel is fine and the best choice.... Yes, I know there are RARE cases where None isn't a good sentinel, but I can't recall the last time I encountered that situation. I've myself made errors with mutable defaults. Perhaps not for a few years, but certainly years after I should have known better. Yes, there genuinely is a possible bug with using defaults. However, I believe that having two different kinds of default parameter bindings would lead to a much larger number of bugs than the status quo. I think this would be true even if the syntax made the distinction obvious... And the '=>' syntax is far from intuitive to start with. It *could* be memorized, but it's definitely not intuitive. This isn't just beginners either. For example, in a few days, I'm giving a short talk about the pitfalls of using lru_cache with mutable arguments to folks at my work. They have, typically, 5-10 years Python experience, yet that's an error I've found in production code. This really isn't the same issue as this PEP, but it's an example of where just a little extra complexity gets experienced developers confused.