> I don't think we need to be dogmatic here. If someone wants to provide > it on PyPI, then be it. But if they'd rather contribute it to the > stdlib, we should examine the relevant PR at face value.
> Asking it to be exercised first on PyPI is worthwhile if the domain > space is complex or there are multiple possible APIs. It's not really > the case here: the API is basically constrained (it must be an > Executor) and the main unknown seems to be whether execution is lazily > or immediate (which may be as well governed by a constructor > parameter). And the implementation shouldn't be very hairy either :-) Alright, fair enough. I suppose that I hadn't adequately considered how constrained the API and straightforward the implementation would likely be. If you think it would very likely receive widespread enough usage to justify adding and maintaining it to the stdlib, I fully trust your judgement on that. (: As a side note, are we still interested in expanding the public API for the Future class? Particularly for a public means of accessing the state. The primary motivation for it was this topic, but I could easily the same issues coming up with custom Future and Executor classes; not to mention the general debugging usefulness for being able to log the current state of the future (without relying on private members). On Sun, Feb 16, 2020 at 9:49 AM Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 16 Feb 2020 09:29:36 -0500 > Kyle Stanley <aeros...@gmail.com> wrote: > > > > After Andrew explained his own use case for it with isolating bugs to > > ensure that the issue wasn't occurring as a result of parallelism, > threads, > > processes, etc; I certainly can see how it would be useful. I could also > > see a use case in a CLI tool for a conveniently similar parallel and > > non-parallel version, although I'd likely prefer just having an entirely > > separate implementation. Particularly if the parallel version includes > > diving a large, computationally intensive task into many sub-tasks (more > > common for PPE), that seems like it could result in significant > additional > > unneeded overhead for the non-parallel version. > > > > I think at this point, it's potential usefulness is clear though. But, > IMO, > > the main question is now the following: would it be better *initially* > > placed in the standard library or on PyPI (which could eventually > > transition into stdlib if it sees widespread usage)? > > I don't think we need to be dogmatic here. If someone wants to provide > it on PyPI, then be it. But if they'd rather contribute it to the > stdlib, we should examine the relevant PR at face value. > > Asking it to be exercised first on PyPI is worthwhile if the domain > space is complex or there are multiple possible APIs. It's not really > the case here: the API is basically constrained (it must be an > Executor) and the main unknown seems to be whether execution is lazily > or immediate (which may be as well governed by a constructor > parameter). And the implementation shouldn't be very hairy either :-) > > Regards > > Antoine. > > _______________________________________________ > 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/U5AOBMMGIANXFJEKMZYMWNQSY7D6RPL5/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/TPT67BK6XWUMYBXVAYVJYL46HXECNCPI/ Code of Conduct: http://python.org/psf/codeofconduct/
