[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed May 26 06:22:01 CEST 2010

On 26/05/10 13:51, Stephen J. Turnbull wrote:

People have been asking "what's special about this module, to violate the BCP principle?" There's nothing special about the fact that several people would use a "robust and debugged" futures module if it were in the stdlib. That's true of every module that is worth a PEP.

I actually wrote a reply to that question earlier in the week, but failed at using gmail's web interface correctly and only sent it to Steve Holden.

=================== The trick with futures and executor pools is that they're a better way of programming with threads in many cases.

However, given the choices of:

I'll choose the first option every time, and my programs will be the worse for it.

Put the capability to use futures and an executor into the stdlib, and it becomes something I can reach for without having to worry about additional dependencies beyond specifying a minimal Python version. It provides a higher level API that can be more readily switched between threading and multiprocessing back ends. It becomes something that can be taught as a standard Python technique for enabling concurrency in imperative code.

This is something that is irrelevant to me as a module on PyPI, but has the potential to significantly affect my programming in the future as a standard library module. Even in the near term, backports of future standard library modules are often perceived differently when being discussed as potential additional dependencies for an application (i.e. I believe it would be worthwhile for a backport of the module to earlier Python versions than 3.2 to be made available on PyPI).

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list