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 _______________________________________________ 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/NYYYAXLQXN3N7OH4SD34QXS2BPETJCS7/ Code of Conduct: http://python.org/psf/codeofconduct/
