On 02/26/2018 11:23 AM, Michał Górny wrote: > W dniu pon, 26.02.2018 o godzinie 10∶09 -0800, użytkownik Zac Medico > napisał: >> On 02/26/2018 04:29 AM, Michał Górny wrote: >>> W dniu nie, 25.02.2018 o godzinie 17∶50 -0800, użytkownik Zac Medico >>> napisał: >>>> Add async_aux_get method that returns a Future and otherwise >>>> behaves identically to aux_get. Use async_aux_get to implement >>>> the synchronous aux_get method. >>>> >>>> Bug: https://bugs.gentoo.org/648790 >>>> --- >>>> pym/portage/dbapi/porttree.py | 91 >>>> +++++++++++++++++++++++++++++++++---------- >>>> 1 file changed, 70 insertions(+), 21 deletions(-) >>>> >>> >>> What's the exact use case? What's the gain, in numbers? >> >> I'm planning to use the for repoman, since it commonly has to generate >> metadata for multiple packages a once, when dealing with ebuild or >> eclass modifications. >> >> The gain in numbers is that it scales linearly with the number of >> available cores. >> >>> This seems like a lot of added complexity. >> >> It doesn't really add complexity, asynchronous code or this sort is >> already used throughout portage internals. Asynchronous methods like >> these are quite standard today, thanks to asyncio. >> >>> With Portage being practically unmaintainable, >> >> Any reasonably complex codebase appears to be unmaintainable to those >> who don't maintain it. >> >>> I'm against any changes that make things worse without >>> clearly defined major benefit. >> >> Transitioning to asynchronous interfaces like this is unavoidable as we >> move into the realm of asyncio compatibility. > > I think we can agree that functions like aux_get() that rely on callers > providing constant parameters to obtain the necessary output are far > from optimal. I believe Portage should aim towards transitioning callers > to more object-oriented APIs.
That's fine but aux_get is a public API that will remain supported until we have a replacement, and async_aux_get will be an immediately useful enhancement to an existing API. > That's why I'm opposed to *proliferating* bad APIs. Maybe I'm wrong but > I don't believe this code would be helpful in transitioning Portage to > object-oriented API. I'd welcome the addition of new APIs, but that should not block the enhancement of existing APIs. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
