I've updated the PEP to include:
- completion callbacks (for interoperability with Twisted Deferreds)
- a pointer to the discussion on stdlig-sig
See:
http://svn.python.org/view/peps/trunk/pep-3148.txt?r1=78618r2=80679
Rejected ideas:
- Having a registration system for executors
Not yet
Nick Coghlan wrote:
You may want to consider providing global thread and process
executors
in the futures module itself. Code which just wants to say do this
in
the background without having to manage the lifecycle of its own
executor instance is then free to do so. I've had a lot of
Brian Quinlan wrote:
I take it that the thread/process pool should be unlimited in size.
Should every thread/process exit when it finishes its job or should
there be a smarter collection strategy?
I'd be inclined to do something slightly smarter, similar to what we do
with memory
On 10 Mar 2010, at 23:32, Nick Coghlan wrote:
Brian Quinlan wrote:
Getting rid of the process-global state like this simplifies testing
(both testing of the executors themselves and of application code
which uses them). It also eliminates the unpleasant interpreter
shutdown/module globals
On 10 Mar 2010, at 08:32, Dj Gilcrease wrote:
On Mon, Mar 8, 2010 at 2:11 PM, exar...@twistedmatrix.com wrote:
Getting rid of the process-global state like this simplifies
testing (both
testing of the executors themselves and of application code which
uses
them). It also eliminates the
On 9 Mar 2010, at 08:39, Greg Ewing wrote:
Terry Reedy wrote:
Looking more close, I gather that the prime results will be printed
'in order' (waiting on each even if others are done) while the url
results will be printed 'as available'.
Seems to me that if you care about the order of the
On 9 Mar 2010, at 08:11, exar...@twistedmatrix.com wrote:
On 08:56 pm, digitalx...@gmail.com wrote:
On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease
digitalx...@gmail.com wrote:
A style I have used in my own code in the past is a Singleton class
with register and create methods, where the
On 9 Mar 2010, at 03:21, Terry Reedy wrote:
On 3/6/2010 4:20 AM, Brian Quinlan wrote:
On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com
mailto:br...@sweetapp.com wrote:
import futures
+1 on the idea, -1 on the name.
Brian Quinlan wrote:
Getting rid of the process-global state like this simplifies testing
(both testing of the executors themselves and of application code
which uses them). It also eliminates the unpleasant interpreter
shutdown/module globals interactions that have plagued a number of
s...@pobox.com wrote:
I'm +1 on adding a nice task queuing system, -1 on calling it by any
other name. ;-)
Nick As Guido said, let's call the nice task queuing system futures
Nick and point people wanting a full-power asynchronous process model
Nick to Twisted
Can
Le Mon, 08 Mar 2010 21:11:45 -,
exar...@twistedmatrix.com a écrit :
Getting rid of the process-global state like this simplifies testing
(both testing of the executors themselves and of application code
which uses them). It also eliminates the unpleasant interpreter
shutdown/module
On 3/8/2010 4:39 PM, Greg Ewing wrote:
Terry Reedy wrote:
Looking more close, I gather that the prime results will be printed
'in order' (waiting on each even if others are done) while the url
results will be printed 'as available'.
Seems to me that if you care about the order of the results,
On Mon, Mar 8, 2010 at 2:11 PM, exar...@twistedmatrix.com wrote:
Getting rid of the process-global state like this simplifies testing (both
testing of the executors themselves and of application code which uses
them). It also eliminates the unpleasant interpreter shutdown/module
globals
P.J. Eby wrote:
I'm +1 on adding a nice task queuing system, -1 on calling it by any
other name. ;-)
As Guido said, let's call the nice task queuing system futures and
point people wanting a full-power asynchronous process model to Twisted
- while the Deferred API may technically be
Dj Gilcrease wrote:
On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller jnol...@gmail.com wrote:
Making the tests and examples happy on windows is fine; but some
explanation is needed for the API changes.
My primary motivation behind the API change is so there is just a
single public Executor
On 3/8/2010 6:14 AM, Nick Coghlan wrote:
P.J. Eby wrote:
I'm +1 on adding a nice task queuing system, -1 on calling it by any
other name. ;-)
As Guido said, let's call the nice task queuing system futures and
I was confused by 'futures' also until Philip explained it as task-queue
or
On 3/6/2010 4:20 AM, Brian Quinlan wrote:
On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com
mailto:br...@sweetapp.com wrote:
import futures
+1 on the idea, -1 on the name. It's too similar to from __future__
import
On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
Wouldn't a factory function serve that purpose just as well? Or even
just from concurrent.futures import ProcessPoolExecutor as TaskExecutor.
That last form has the virtue that you can retrieve your executor from
anywhere
I'm +1 on adding a nice task queuing system, -1 on calling it by any
other name. ;-)
Nick As Guido said, let's call the nice task queuing system futures
Nick and point people wanting a full-power asynchronous process model
Nick to Twisted
Can this module at least be
On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease digitalx...@gmail.com wrote:
A style I have used in my own code in the past is a Singleton class
with register and create methods, where the register takes a
name(string) and the class and the create method takes the name and
*args, **kwargs and
On 08:56 pm, digitalx...@gmail.com wrote:
On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease digitalx...@gmail.com
wrote:
A style I have used in my own code in the past is a Singleton class
with register and create methods, where the register takes a
name(string) and the class and the create method
Terry Reedy wrote:
Looking more close, I gather that the prime
results will be printed 'in order' (waiting on each even if others are
done) while the url results will be printed 'as available'.
Seems to me that if you care about the order of the results,
you should be able to just wait for
Dj Gilcrease wrote:
executor = executors.create(NAME, *args, **kwargs) # NAME is 'process'
or 'thread' by default
from concurrent.futures import executors, ExecutorBase
class MyExecutor(ExecutorBase): ...
executors.register(NAME, MyExecutor)
I don't understand the reason for using a
On Sat, Mar 6, 2010 at 10:09 PM, Dj Gilcrease digitalx...@gmail.com wrote:
After playing with the API for a while running into many issues with
the examples tests crashing windows I decided to modify the API a
little and fix up the examples so they dont crash windows based
computers.
At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
P.J. Eby wrote:
(Personally, I think it would be better to just drop the ambitious title
and scope, and go for the nice task queue scope. I imagine, too, that
in that case Jean-Paul wouldn't need to worry about it being raised as a
future
On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby p...@telecommunity.com wrote:
At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
P.J. Eby wrote:
(Personally, I think it would be better to just drop the ambitious title
and scope, and go for the nice task queue scope. I imagine, too, that
in that
At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby p...@telecommunity.com wrote:
At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
P.J. Eby wrote:
(Personally, I think it would be better to just drop the ambitious title
and scope, and go for the nice
On Sun, 07 Mar 2010 10:48:09 -0500, P.J. Eby p...@telecommunity.com wrote:
At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
I agree the PEP should just target what the current implementation
provides and put whatever scope limitations are needed in the preamble
text to make that clear.
Yep.
On Sun, Mar 7, 2010 at 9:57 AM, P.J. Eby p...@telecommunity.com wrote:
At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
Do you have an example of a language or library that uses the term
future to refer to what you're talking about? I'm curious to see
what it looks like.
The wikipedia page
At 10:59 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
So is it that you just don't like the idea of blocking, and want to
stop anything that relies on it from getting into the standard library?
Um, no. As I said before, call it a parallel task queue or
parallel task manager or something to that
On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller jnol...@gmail.com wrote:
Making the tests and examples happy on windows is fine; but some
explanation is needed for the API changes.
My primary motivation behind the API change is so there is just a
single public Executor class that you tell what
On Sun, Mar 7, 2010 at 11:56 AM, P.J. Eby p...@telecommunity.com wrote:
At 10:59 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
So is it that you just don't like the idea of blocking, and want to stop
anything that relies on it from getting into the standard library?
Um, no. As I said before,
On 6 Mar 2010, at 07:38, Brett Cannon wrote:
The PEP says that futures.wait() should only use keyword arguments
past its first positional argument, but the PEP has the function
signature as ``wait(fs, timeout=None, return_when=ALL_COMPLETED)``.
Should it be ``wait(fs, *, timeout=None,
On 6 Mar 2010, at 08:42, Jesse Noller wrote:
If people agree with this; do you feel the proposal of said namespace
should be a separate PEP, or piggy back on this? I don't want to piggy
back on Brian's hard work.
It doesn't really matter to me.
We can either update this PEP to propose the
On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan br...@sweetapp.com a écrit :
The PEP lives here:
http://python.org/dev/peps/pep-3148/
Ok, here is my take on it:
cancel()
Attempt to cancel the call. If the call is currently being executed
Brian Quinlan wrote:
On 6 Mar 2010, at 08:42, Jesse Noller wrote:
If people agree with this; do you feel the proposal of said namespace
should be a separate PEP, or piggy back on this? I don't want to piggy
back on Brian's hard work.
It doesn't really matter to me.
We can either update
Jeffrey Yasskin writes:
It seems like a good idea to follow the choice other languages have
used for the name (if they tend to agree)
For the record, I've conceded that point.
___
Python-Dev mailing list
Python-Dev@python.org
Brian Quinlan wrote:
IOW, as far as I can tell from the PEP, it doesn't look like you can
compose futures without *global* knowledge of the application... and
in and of itself, this seems to negate the PEP's own motivation to
prevent duplication of parallel execution handling!
That is, if I
On Sat, Mar 6, 2010 at 6:43 AM, Nick Coghlan ncogh...@gmail.com wrote:
You may want to consider providing global thread and process executors
in the futures module itself. Code which just wants to say do this in
the background without having to manage the lifecycle of its own
executor
I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/
When I was running in debug mode I found that as soon as
p = multiprocessing.Process(
I am also getting an odd error on odd error on exit
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found
___
Python-Dev mailing list
Python-Dev@python.org
On Mar 6, 2010, at 4:20 PM, Dj Gilcrease digitalx...@gmail.com wrote:
I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/
When I was running in debug mode I
Stephen J. Turnbull step...@xemacs.org writes:
I have to admit Jean-Paul's explanation a pretty convincing reason for
adopting future rather than promise. But I'm with Skip, I would
prefer that the module be named future rather than futures.
Has anyone in this very long thread raised the
On Mar 6, 2010, at 5:47 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
Stephen J. Turnbull step...@xemacs.org writes:
I have to admit Jean-Paul's explanation a pretty convincing reason
for
adopting future rather than promise. But I'm with Skip, I would
prefer that the module be named
Jeffrey Yasskin wrote:
The caller can't avoid the error here by querying the future, because
of the problem you point out below, so I'm inclined to think that the
future was already started should be a return value rather than an
exception (although that may be my C++ background showing
Phillip J. Eby wrote:
while at the same time creating yet another alternative (and
mutually incompatible) event loop system in the stdlib, beyond the ones
that are already in asyncore, tkinter, and the various SocketServer
subclasses.
Aaargh... that's the *last* thing we need!
I've been
On 06/03/2010 23:37, Greg Ewing wrote:
Phillip J. Eby wrote:
while at the same time creating yet another alternative (and mutually
incompatible) event loop system in the stdlib, beyond the ones that
are already in asyncore, tkinter, and the various SocketServer
subclasses.
Aaargh... that's
Brian Quinlan wrote:
That recommendation was designed to make it easy to change the API
without breaking code.
I'd don't think that recommendation makes sense anymore any I'll update
the PEP.
I don't think there's anything wrong with stating that the
order of the arguments is not a
On Sat, Mar 6, 2010 at 5:38 PM, Michael Foord fuzzy...@voidspace.org.ukwrote:
On 06/03/2010 23:37, Greg Ewing wrote:
I've been thinking for a while that it would be a big help
if there were one, standardised module in the stdlib for
handling async events, and all the other gui toolkits
etc.
Michael Foord wrote:
Wouldn't it have to be the Tcl event loop then?
No, tcl/tk would have to be threatened with the comfy chair
until it allowed itself to be spliced into the official
event loop somehow.
--
Greg
___
Python-Dev mailing list
Ben Has anyone in this very long thread raised the issue that Python
Ben *already* uses this term for the name of a module with a totally
Ben unrelated purpose; the â__future__â pseudo-module?
Yes, it's already come up. While not quite the same it does remind me of
the
On Sat, Mar 6, 2010 at 2:58 PM, Jesse Noller jnol...@gmail.com wrote:
Did you run the provided example code on windows by chance? If so, look at
the multiprocessing docs, there are restrictions on windows (see the
__main__ note) - not following the guidelines can result in lots of
processes
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's Deferred API has nothing to do with I/O.
I see, you just mean the API and not the
On 02:10 am, br...@sweetapp.com wrote:
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's Deferred API has nothing to do with I/O.
I
On Sat, Mar 6, 2010 at 9:34 PM, exar...@twistedmatrix.com wrote:
On 02:10 am, br...@sweetapp.com wrote:
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code.
After playing with the API for a while running into many issues with
the examples tests crashing windows I decided to modify the API a
little and fix up the examples so they dont crash windows based
computers.
http://code.google.com/p/pythonfutures/issues/detail?id=1
API Change that changes
At 01:10 PM 3/7/2010 +1100, Brian Quinlan wrote:
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's Deferred API has nothing to do
Greg Ewing wrote:
The thing to consider, I think, is whether it makes sense in
a large proportion of use cases to ignore the fact that the
cancel failed and carry on regardless. If not, then raising an
exception makes it much harder to accidentally ignore the
situation.
Cancelling operations
P.J. Eby wrote:
(Personally, I think it would be better to just drop the ambitious title
and scope, and go for the nice task queue scope. I imagine, too, that
in that case Jean-Paul wouldn't need to worry about it being raised as a
future objection to Deferreds or some such getting into the
A young library solving an old problem in a way that conflicts with
many of the other implementations available for years and with zero
apparent users in the wild is not an appropriate candidate for a PEP.
On Fri, Mar 5, 2010 at 1:03 AM, Brian Quinlan br...@sweetapp.com wrote:
Hi all,
I
On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman ironfro...@gmail.com wrote:
A young library solving an old problem in a way that conflicts with
many of the other implementations available for years and with zero
apparent users in the wild is not an appropriate candidate for a PEP.
Baloney. A
I revert my objections. I still would like to see this in use in the
wild and I might even use it thusly, myself.
On Fri, Mar 5, 2010 at 9:50 AM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman ironfro...@gmail.com wrote:
A young library solving an old
Jesse Noller wrote:
The reason *why* is that I would like to also move the abstractions I
have in multiprocessing *out* of that module, make them work with both
threads and processes (if it makes sense) and reduce the
multiprocessing module to the base primitive Process object. A
concurrent
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com wrote:
import futures
+1 on the idea, -1 on the name. It's too similar to from __future__ import
Also, the PEP should probably link to the discussions on stdlib-sig?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach
import futures
+1 on the idea, -1 on the name. It's too similar to from __future__
import
Jesse Futures is a common term for this, and implemented named this in
Jesse other languages. I don't think we should be adopting things that
Jesse are common, and
On Fri, Mar 5, 2010 at 11:56 AM, s...@pobox.com wrote:
import futures
+1 on the idea, -1 on the name. It's too similar to from __future__
import
Jesse Futures is a common term for this, and implemented named this in
Jesse other languages. I don't think we
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com wrote:
import futures
+1 on the idea, -1 on the name. It's
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller jnol...@gmail.com wrote:
http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
According to that link, Java has a module named Concurrent with an
interface named Future. You're proposing a module named Futures with a
class named
Jesse
http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
Without reading that I can assure you that not everybody has drunk the Java
Kool-Aid. Just because Sun thought it was a fine term doesn't mean everyone
else will. I've been a professional programmer for about 30
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller jnol...@gmail.com wrote:
http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
According to that link, Java has a module named Concurrent
On 05:06 pm, c...@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com
wrote:
import futures
On Fri, Mar 5, 2010 at 9:55 AM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller jnol...@gmail.com wrote:
s...@pobox.com wrote:
Jesse
http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
Without reading that I can assure you that not everybody has drunk the Java
Kool-Aid. Just because Sun thought it was a fine term doesn't mean everyone
else will. I've been a
http://home.pipeline.com/~hbaker1/Futures.html (1977)
___
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
On Fri, Mar 5, 2010 at 10:30 AM, exar...@twistedmatrix.com wrote:
On 05:06 pm, c...@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at
On 07:10 pm, gu...@python.org wrote:
On Fri, Mar 5, 2010 at 10:30 AM, exar...@twistedmatrix.com wrote:
On 05:06 pm, c...@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller jnol...@gmail.com
wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
On Fri, Mar 5, 2010 at 09:55, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller jnol...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com wrote:
import futures
+1 on the idea, -1 on the name. It's too similar
The PEP says that futures.wait() should only use keyword arguments past its
first positional argument, but the PEP has the function signature as
``wait(fs, timeout=None, return_when=ALL_COMPLETED)``. Should it be
``wait(fs, *, timeout=None, return_when=ALL_COMPLETED)``?
On Thu, Mar 4, 2010 at
On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon br...@python.org wrote:
So I don't quite get what you are after here. Are you wanting to eventually
have a generic pool class that you can simply import and use that is always
set to the best option for the platform?
And as for moving stuff from
On Fri, Mar 5, 2010 at 12:18 PM, exar...@twistedmatrix.com wrote:
The explicit futures on the wikipedia page seems to cover what is commonly
referred to as a future. For example, Java's futures look like this.
The implicit futures are what is generally called a promise. For example,
E's
On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan
On Fri, Mar 5, 2010 at 1:42 PM, Jesse Noller jnol...@gmail.com wrote:
On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan br...@sweetapp.com a écrit :
The PEP lives here:
http://python.org/dev/peps/pep-3148/
Ok, here is my take on it:
cancel()
Attempt to cancel the call. If the call is currently being executed
then it cannot be cancelled and the method will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com
On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan br...@sweetapp.com a écrit :
The PEP lives here:
http://python.org/dev/peps/pep-3148/
Ok, here is my take on it:
cancel()
Attempt to cancel the call. If the call is
Guido van Rossum writes:
Future is a pretty standard CS term for this concept (as noted
promise is another),
I like the term promise better. Future is very generic (not now,
but later), whereas a promise is something I don't get from you
now, but you will give me later.
The wikipedia
exar...@twistedmatrix.com writes:
The explicit futures on the wikipedia page seems to cover what is
commonly referred to as a future. For example, Java's futures look like
this.
The implicit futures are what is generally called a promise. For
example, E's promises look like
At 01:03 AM 3/5/2010, Brian Quinlan wrote:
Hi all,
I recently submitted a daft PEP for a package designed to make it
easier to execute Python functions asynchronously using threads and
processes. It lets the user focus on their computational problem
without having to build explicit
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby p...@telecommunity.com wrote:
I'm somewhat concerned that, as described, the proposed API ... [creates] yet
another alternative (and
mutually incompatible) event loop system in the stdlib ...
Futures are a blocking construct; they don't involve
At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote:
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby p...@telecommunity.com wrote:
I'm somewhat concerned that, as described, the proposed API ...
[creates] yet another alternative (and
mutually incompatible) event loop system in the stdlib ...
Hi all,
I recently submitted a daft PEP for a package designed to make it
easier to execute Python functions asynchronously using threads and
processes. It lets the user focus on their computational problem
without having to build explicit thread/process pools and work queues.
The
92 matches
Mail list logo
