A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-May/100320.html below:

[Python-Dev] PEP 3148 ready for pronouncement

[Python-Dev] PEP 3148 ready for pronouncementNick 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:
- 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4