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/
