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:
- hack together something simple with some worker Threads and a Queue
(or two)
- write my own futures and executor infrastructure
- download a futures module from PyPI and live with the additional
dependency
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 | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
