On Sat, Dec 4, 2021, 10:14 PM Rob Cliffe via Python-ideas > The designers of 12 languages have chosen to provide late binding; those > of 3 or 4 have provided early binding. > I think this is at least tenuous evidence in favour of my belief that late > binding is more useful than early binding. >
As the person probably most vociferous in opposing this PEP, I absolutely agree that late-binding is more useful. If I were creating a new programming language today, I would certainly make arguments be evaluated on call, not on definition. There are perfectly good ways to "fake" either one if you only have the other. Probably more work is needed to simulate early binding, but there are ways to achieve the same effect. However, that language would not be Python. That ship sailed in 1991. What's being discussed here isn't changing the behavior of binding in `def f(foo=bar)`. Instead, it's a discussion of adding ADDITIONAL syntax for late-binding behavior. I think the proposed syntax is the worst of all the options discussed. But the real issue is that the cases where it is relevant are vanishingly rate, and the extra cognitive, teaching, and maintenance burden is significant. In 90%+ of the functions I've written, default arguments are non-sentinel immutable values. If those were late bound, nothing whatsoever would change. Yes, maybe slightly different bytecodes would exist, but at the Python level, everything works work the same. So this issue only issue is only remotely relevant to <10% of functions with default arguments. However, of those <10%, 98% work perfectly fine with None as a sentinel. Probably fewer than half of functions I've written use named parameters at all. In other words, for somewhere fewer than one in a thousand functions, this new syntax might serve any purpose at all. That purpose is predominantly "avoid using a custom sentinel." A custom sentinel is a SMALL lift. I agree that a custom sentinel, while rare, is a slight wart in a program. I also believe that in this 1/1000 case, there could be a slightly prettier automatic docstrings. But not prettier than writing an explicit docstring in any case. The cost here is that EVERY SINGLE student learning Python needs to add this new construct to their mental load. EVERY book and tutorial needs to be updated. EVERY experienced developer has to spend extra effort understanding and writing code. The COST of implementing this PEP is *quite literally* tens of millions of person days. The benefit is a rare savings of two lines of function body code or a docstring line.
_______________________________________________ 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/EHLOIHUL4B56TDI7PRYYJXMXVXYORSCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
