No, and there shouldn’t be written criteria. That would just give people more incentive to argue forever.
On Fri, Mar 19, 2021 at 10:12 Luciano Ramalho <luci...@ramalho.org> wrote: > Now is a good time to ask: what are the criteria for adding functions to > the builtins module? > > Is there a written record of those criteria? > > Thanks! > > > On Fri, Mar 19, 2021 at 1:55 PM Luciano Ramalho <luci...@ramalho.org> > wrote: > >> OK, but it seems clear to me that if there are any lingering doubts it >> would be better to add the functions to a module than to the built-ins, and >> later promote them to built-ins if people actually find them widely useful. >> >> On the other hand, adding something to built-ins that turns out to be >> rarely useful adds unnecessary noise and is much harder to fix later >> without causing further problems. >> >> Best, >> >> Luciano >> >> >> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson <jabron...@gmail.com> >> wrote: >> >>> Thanks for taking a look at this, Luciano. >>> >>> Yury immediately replied <https://bugs.python.org/issue31861#msg319520> >>> to the comment from Jelle that you quoted with the following: >>> >>> > Do these really need to be builtins? >>>> >>>> We're only beginning to see async iterators being used in the wild, so >>>> we can't have a definitive answer at this point. >>>> >>>> > They seem too specialized to be widely useful; I've personally never >>>> needed them in any async code I've written. It would make more sense to me >>>> to put them in a module like operators. >>>> >>>> I think putting them to the operators module makes sense, at least for >>>> 3.8. Do you want to work on a pull request? >>> >>> >>> >>> That was on 2018-06-14. On 2018-08-24, I submitted >>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and >>> operator.anext". On 2018-09-07, Yury left the following comment >>> <https://github.com/python/cpython/pull/8895#pullrequestreview-153441599> >>> on that PR: >>> >>> Please don't merge this yet. I'm not convinced that aiter and anext >>>> shouldn't be builtins. >>> >>> >>> >>> So there has been some back-and-forth on this, and some more years have >>> passed, but all the latest signals we've gotten up to now have indicated a >>> preference for adding these to builtins. >>> >>> In any case, as of my latest PR >>> <https://github.com/python/cpython/pull/23847>, the Python core >>> developers now have both options to choose from. >>> >>> As community contributors, is there anything further we can do to help >>> drive timely resolution on this one way or another? >>> >>> Thanks, >>> Josh >>> >>> >>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho <luci...@ramalho.org> >>> wrote: >>> >>>> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra >>>> in the issue tracker: >>>> >>>> Do these really need to be builtins? >>>> >>>> They seem too specialized to be widely useful; I've personally never >>>> needed them in any async code I've written. It would make more sense to me >>>> to put them in a module like operators. >>>> >>>> >>>> (sorry for the weird formatting, posting from an iPad) >>>> >>>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson <jabron...@gmail.com> >>>> wrote: >>>> >>>>> Dear python-dev, >>>>> >>>>> New here (but not to Python). đź‘‹ Brett Cannon recommended I start a >>>>> thread here (thanks, Brett!). >>>>> >>>>> In December, two colleagues and I submitted >>>>> https://github.com/python/cpython/pull/23847, "Add aiter and anext to >>>>> builtins", which would fix https://bugs.python.org/issue31861. >>>>> >>>>> Would any core developers who may be reading this be willing and able >>>>> to provide a code review? >>>>> >>>>> We would love to try to address any review feedback before having to >>>>> fix (another round of) merge conflicts. (And ideally maybe even get this >>>>> landed in time for the 3.10 feature freeze in early May?) >>>>> >>>>> Thanks and hope this finds you well. >>>>> _______________________________________________ >>>>> Python-Dev mailing list -- python-dev@python.org >>>>> To unsubscribe send an email to python-dev-le...@python.org >>>>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>>>> Message archived at >>>>> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/ >>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>>> >>>> -- >>>> Luciano Ramalho >>>> | Author of Fluent Python (O'Reilly, 2015) >>>> | http://shop.oreilly.com/product/0636920032519.do >>>> | Technical Principal at ThoughtWorks >>>> | Twitter: @ramalhoorg >>>> >>> >> >> -- >> Luciano Ramalho >> | Author of Fluent Python (O'Reilly, 2015) >> | http://shop.oreilly.com/product/0636920032519.do >> | Technical Principal at ThoughtWorks >> | Twitter: @ramalhoorg >> > > > -- > Luciano Ramalho > | Author of Fluent Python (O'Reilly, 2015) > | http://shop.oreilly.com/product/0636920032519.do > | Technical Principal at ThoughtWorks > | Twitter: @ramalhoorg > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/U6XHIDU43A2WGEUU5PCMH6SHD6NXQ273/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile)
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DIZA6CAIEEHQAGFGDCMLSALDP6BGDEEE/ Code of Conduct: http://python.org/psf/codeofconduct/
