On Tue, Oct 26, 2021 at 10:44 PM Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Oct 27, 2021 at 1:13 PM Ricky Teachey <ri...@teachey.org> wrote: > > > > I'll try to summarize why I still have pause even though after thinking > about it I still can't really think of a solid example showing that this > "give me the default" issue is a concrete problem: > > > > Until this point, exactly how to provide a default argument value has > been the Wild West in python, and as Paul Moore said, there's really not a > way to introspect whether a parameter was "defaulted". The result is that a > cornucopia of APIs have flourished. By necessity, all these previous APIs > provided ways to ask for the default through passing some special value, > and this has felt like "the pythonic way"for a night time. We are all used > to it (but perhaps only tolerated it in many cases). > > > > The proposal blesses a new API with language support, and it will > suddenly become THE pythonic approach. But this newly blessed, pythonic API > is a radical departure from years- decades- of coding habits. > > > > That's a very good point, but I'd like to turn it on its head and > explain the situation from the opposite perspective. > > For years - decades - Python has lacked a way to express the concept > that a default argument is something more than a simple value. Coders > have used a variety of workarounds. In the future, most or all of > those workarounds will no longer be necessary, and we will have a > single obvious way to do things. > > Suppose that, up until today, Python had not had support for big > integers - that the only numbers representable were those that fit > inside a 32-bit (for compatibility, of course) two's complement > integer. People who need to work with larger numbers would use a > variety of tricks: storing digits in strings and performing arithmetic > manually, or using a tuple of integers to represent a larger number, > or using floats and accepting a loss of precision. Then Python gains > native support for big integers. Yes, it would be a radical departure > from years of workarounds. Yes, some people would continue to use the > other methods, because there would be enough differences to warrant > it. And yes, there would be backward-incompatible API changes as edge > cases get cleaned up. Is it worth it? For integers, I can respond with > a resounding YES, because we have plenty of evidence that they are > immensely valuable! With default argument expressions, it's less of an > obvious must-have, but I do believe that the benefits outweigh the > costs. > > Will the standard library immediately remove all "=None" workaround > defaults? No. Probably some of them, but not all. Will there be > breakage as a result of something passing None where it wanted the > default? Probably - if not in the stdlib, then I am sure it'll happen > in third-party code. Will future code be more readable as a result? > Absolutely. > > ChrisA > If I might paraphrase Agrippa from the book of Acts: "Almost thou persuadest me..." ;) It's a fine answer. <http://python.org/psf/codeofconduct/> Thanks for the attentiveness to my concern, Chris. Very much appreciated! --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
_______________________________________________ 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/UCQSCITR6RWUNLFZ73WAFCC2X3HCQO7M/ Code of Conduct: http://python.org/psf/codeofconduct/
