Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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=78618&r2=80679 Rejected ideas: - Having a registration system for executors Not yet addres

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 overallocat

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 o

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 int

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 T

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 mailto:br...@sweetapp.com>> wrote: import futures +1 on the idea, -1 on the name. It's too similar to "

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 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(stri

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 10 Mar 2010, at 08:32, Dj Gilcrease wrote: On Mon, Mar 8, 2010 at 2:11 PM, 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 shu

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Mon, Mar 8, 2010 at 2:11 PM, 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 pla

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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,

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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/modul

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 registrat

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 eac

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 08:56 pm, digitalx...@gmail.com wrote: On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease 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 *ar

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease 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 acts as a factory.

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

>> 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan 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 rather than

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 mailto: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 sh

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 tas

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

Dj Gilcrease wrote: > On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 indepen

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 11:56 AM, P.J. Eby 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, call it a "paral

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller 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 system to use ins

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 t

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 9:57 AM, P.J. Eby 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 menetioned

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, 07 Mar 2010 10:48:09 -0500, "P.J. Eby" 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. I'm just sa

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote: On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby 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 case Jean

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sat, Mar 6, 2010 at 10:09 PM, Dj Gilcrease 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. > > http://code.google.

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 operat

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 w

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 t

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sat, Mar 6, 2010 at 9:34 PM, 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. Futur

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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.

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 th

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sat, Mar 6, 2010 at 2:58 PM, Jesse Noller 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 spawning. Yes,

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 __built

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 Python-D

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sat, Mar 6, 2010 at 5:38 PM, Michael Foord wrote: > 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. were made to us

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 guarante

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 t

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 thin

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 throug

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Mar 6, 2010, at 5:47 PM, Ben Finney wrote: "Stephen J. Turnbull" 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

"Stephen J. Turnbull" 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 issue that

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Mar 6, 2010, at 4:20 PM, Dj Gilcrease 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 found that as soon as

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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(

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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. ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sat, Mar 6, 2010 at 6:43 AM, 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 fre

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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! >> >> Th

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 http://mail.python.o

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 ei

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 6 Mar 2010, at 17:50, Phillip J. Eby wrote: At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote: On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby > wrote: > I'm somewhat concerned that, as described, the proposed API ... [creates] yet another alternative (and > mutually incompatible) event loop sy

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 6 Mar 2010, at 09:54, Antoine Pitrou wrote: Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan 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 ca

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 con

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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, retu

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan 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? I thought about

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 9:47 PM, Stephen J. Turnbull wrote: > 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote: On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby 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 cons

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby 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 an event loop. _

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 thread/proces

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 wi

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou wrote: > Le Fri, 5 Mar 2010 17:03:02 +1100, > Brian Quinlan 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 exec

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: > On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jesse Noller wrote: >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: On Fri, Mar 5, 2010 at 12:03

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan 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 return False

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 1:42 PM, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jesse Noller wrote: >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quin

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jesse Noller wrote: >> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >> wrote: >>> On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: import futures >>> +1 on the idea, -1 on the

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 12:18 PM, 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 promises look like

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon 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 multiprocessi

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 22:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: > On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach > wrote: >> On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: >>> import futures >> +1 on the idea, -1 on the name. It's too similar to "from __future__ import >> ...". > >

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 09:55, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach > wrote: > > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: > >> > >> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > > > > According to that link, Java has a mo

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 07:10 pm, gu...@python.org wrote: On Fri, Mar 5, 2010 at 10:30 AM, wrote: On 05:06 pm, c...@hagenlocher.org wrote: On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan > wrote:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 10:30 AM, wrote: > On 05:06 pm, c...@hagenlocher.org wrote: >> >> On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: >>> >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: >>> > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan >>> > wrote: >>> >> >>> >> impo

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 9:55 AM, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach > wrote: >> On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: >>> >>> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html >> >>  According to that link, Java has a module

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 05:06 pm, c...@hagenlocher.org wrote: On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: >> >> import futures > > +1 on the idea, -1 on the name.  It's too similar to "from

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller 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'r

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller 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 "Future".

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: > > On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach > wrote: > > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: > >> > >> import futures > > > > +1 on the idea, -1 on the name.  It's too similar to "from __future__ import > > ...". > >

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:56 AM, 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 w

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

>>> 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 co

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: >> >> import futures > > +1 on the idea, -1 on the name.  It's too similar to "from __future__ import > ...". Futures is a common term for this, and implemented named this in other la

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan 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 Enterprises, LLC

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 > concurre

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 wrote: > On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman wrote: >> A young library solving an old problem in a way that conflicts with

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman 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 young library pro

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 wrote: > Hi all, > > I recently submitted a d

[Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 package