On 23/05/10 22:47, Antoine Pitrou wrote:
On Sun, 23 May 2010 08:34:22 -0400
Jesse Nollerjnol...@gmail.com wrote:
Brian has already agreed to name spacing it to concurrent.futures -
this means it will be a small part to a much larger concurrent.*
implementation ala Java.
What I would
On 23/05/10 21:56, Lennart Regebro wrote:
On Sun, May 23, 2010 at 13:29, Brian Quinlanbr...@sweetapp.com wrote:
Parts of it, yes. Just like I can replace most operations in os.path and
urlparse with a few lines of code.
Yeah, but parts of is not the question. I've read the PEP, and I do
(Sending again - I didn't mean to drop python-dev from the cc list when
I originally sent this via the gmail web interface)
On Sun, May 23, 2010 at 9:00 PM, Dirkjan Ochtman dirk...@ochtman.nl
mailto:dirk...@ochtman.nl wrote:
Right, it wasn't intended as that harsh... but it does come with
On 20/05/10 08:13, Yaniv Aknin wrote:
Hi,
I wanted to let python-dev know about a series of articles about
CPython's internals I'm publishing under the collective title Guido's
Python* (http://tech.blog.aknin.name/tag/guidos-python/).
A resource that may be useful to you is a 2.5 focused
On Tue, May 25, 2010 at 7:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 23/05/10 22:47, Antoine Pitrou wrote:
On Sun, 23 May 2010 08:34:22 -0400
Jesse Nollerjnol...@gmail.com wrote:
Brian has already agreed to name spacing it to concurrent.futures -
this means it will be a small part to
On Wed, May 26, 2010 at 02:10, Nick Coghlan ncogh...@gmail.com wrote:
Those that say just put it on PyPI may not recognise the additional ...
Just a note, so we don't get sidelined by misunderstandings: I don't
think anybody said that. ;-)
There are two issues here, one generic and one
On 26/05/10 12:29, Lennart Regebro wrote:
On Wed, May 26, 2010 at 02:10, Nick Coghlanncogh...@gmail.com wrote:
Those that say just put it on PyPI may not recognise the additional ...
Just a note, so we don't get sidelined by misunderstandings: I don't
think anybody said that. ;-)
Nah, that
On 24/05/10 20:46, Stephen J. Turnbull wrote:
Cameron Simpson writes:
There's a lot to be said for a robust implementation of a well defined
problem. Brian's module, had it been present and presuming it robust and
debugged, would have been quite welcome.
That, of course, is the
Nick Coghlan writes:
Those that say just put it on PyPI
Nobody is saying that, AFAICS. Nobody is saying that *some* futures
module shouldn't *eventually* go into the stdlib.
The question is whether *this* futures module should go into the
stdlib *now*. And it is clear that more time on PyPI
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*
10 matches
Mail list logo
