[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 has been discussed on stdlib-sig but now I'd like this group's feedback. The PEP lives here: http://python.org/dev/peps/pep-3148/ Here are two examples to whet your appetites: """Determine if several numbers are prime.""" import futures import math PRIMES = [ 112272535095293, 112582705942171, 112272535095293, 115280095190773, 115797848077099, 1099726899285419] def is_prime(n): if n % 2 == 0: return False sqrt_n = int(math.floor(math.sqrt(n))) for i in range(3, sqrt_n + 1, 2): if n % i == 0: return False return True # Uses as many CPUs as your machine has. with futures.ProcessPoolExecutor() as executor: for number, is_prime in zip(PRIMES, executor.map(is_prime, PRIMES)): print('%d is prime: %s' % (number, is_prime)) """Print out the size of the home pages of various new sites (and Fox News).""" import futures import urllib.request URLS = ['http://www.foxnews.com/', 'http://www.cnn.com/', 'http://europe.wsj.com/', 'http://www.bbc.co.uk/', 'http://some-made-up-domain.com/'] def load_url(url, timeout): return urllib.request.urlopen(url, timeout=timeout).read() with futures.ThreadPoolExecutor(max_workers=5) as executor: # Create a future for each URL load. future_to_url = dict((executor.submit(load_url, url, 60), url) for url in URLS) # Iterate over the futures in the order that they complete. for future in futures.as_completed(future_to_url): url = future_to_url[future] if future.exception() is not None: print('%r generated an exception: %s' % (url, future.exception())) else: print('%r page is %d bytes' % (url, len(future.result()))) Cheers, Brian
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 <brian@sweetapp.com> 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/process pools and work queues.
The package has been discussed on stdlib-sig but now I'd like this group's feedback.
The PEP lives here: http://python.org/dev/peps/pep-3148/
Here are two examples to whet your appetites:
"""Determine if several numbers are prime.""" import futures import math
PRIMES = [ 112272535095293, 112582705942171, 112272535095293, 115280095190773, 115797848077099, 1099726899285419]
def is_prime(n): if n % 2 == 0: return False
sqrt_n = int(math.floor(math.sqrt(n))) for i in range(3, sqrt_n + 1, 2): if n % i == 0: return False return True
# Uses as many CPUs as your machine has. with futures.ProcessPoolExecutor() as executor: for number, is_prime in zip(PRIMES, executor.map(is_prime, PRIMES)): print('%d is prime: %s' % (number, is_prime))
"""Print out the size of the home pages of various new sites (and Fox News).""" import futures import urllib.request
URLS = ['http://www.foxnews.com/', 'http://www.cnn.com/', 'http://europe.wsj.com/', 'http://www.bbc.co.uk/', 'http://some-made-up-domain.com/']
def load_url(url, timeout): return urllib.request.urlopen(url, timeout=timeout).read()
with futures.ThreadPoolExecutor(max_workers=5) as executor: # Create a future for each URL load. future_to_url = dict((executor.submit(load_url, url, 60), url) for url in URLS)
# Iterate over the futures in the order that they complete. for future in futures.as_completed(future_to_url): url = future_to_url[future] if future.exception() is not None: print('%r generated an exception: %s' % (url, future.exception())) else: print('%r page is %d bytes' % (url, len(future.result())))
Cheers, Brian _______________________________________________ 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/ironfroggy%40gmail.com
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman <ironfroggy@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 young library providing some syntactic sugar which uses primitives in the standard library to implement a common pattern is fine for a PEP. We've hashed this out pretty heavily on the stdlib-sig list prior to bringing it here. By the same argument, we should shunt all of the recent unittest changes and improvements into space, since golly, other people did it, why should we. This is something relatively simple, which I would gladly add in an instant to the multiprocessing package - but Brian's one-upped me in that regard and is providing something which works with both threads and processes handily. Take a look at multiprocessing.Pool for example - all that is some sugar on top of the primitives, but it's good sugar, and is used by a fair number of people. Let me also state - "my" vision of where futures would live would be in a concurrent package - for example: from concurrent import futures 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 package which implements common patterns built on top of the primitives we support is an objectively Good Thing. For example, how many of us have sat down and implemented a thread pool on top of threading, I would hazard to say that most of us who use threading have done this, and probably more than once. It stands to reason that this is a common enough pattern to include in the standard library. In any case; consider me a strong +1 to adding it. jesse
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 <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman <ironfroggy@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 young library providing some syntactic sugar which uses primitives in the standard library to implement a common pattern is fine for a PEP. We've hashed this out pretty heavily on the stdlib-sig list prior to bringing it here. By the same argument, we should shunt all of the recent unittest changes and improvements into space, since golly, other people did it, why should we.
This is something relatively simple, which I would gladly add in an instant to the multiprocessing package - but Brian's one-upped me in that regard and is providing something which works with both threads and processes handily. Take a look at multiprocessing.Pool for example - all that is some sugar on top of the primitives, but it's good sugar, and is used by a fair number of people.
Let me also state - "my" vision of where futures would live would be in a concurrent package - for example:
from concurrent import futures
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 package which implements common patterns built on top of the primitives we support is an objectively Good Thing.
For example, how many of us have sat down and implemented a thread pool on top of threading, I would hazard to say that most of us who use threading have done this, and probably more than once. It stands to reason that this is a common enough pattern to include in the standard library.
In any case; consider me a strong +1 to adding it.
jesse
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
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 package which implements common patterns built on top of the primitives we support is an objectively Good Thing.
Yes, I've often thought we should have a pool model that covers threads as well as processes. The reason I think "futures" works as a PEP and potential standard library addition is that it is small enough to be readily reviewed and maintained, and serves as a useful building block for more complex usage. For a developer to get anything similar from a third party library is almost certainly going to require buying into a much heavier framework. A simple futures module provides a way to farm out worker tasks in a standard fashion without having to build as much of your own infrastructure every time. I've read the various PEP checkins as they went by on the checkins list - it gets a +0 from me (the only reason it isn't a +1 is because I personally tend to write with a Thread+Queue style. However, I could easily become a futures convert if they were readily available in the standard library) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@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 Enterprises, LLC <http://stutzbachenterprises.com>
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
>>> 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 found elsewhere and then renaming them. Perhaps, but is it a common term for Python programmers (or the target population for Python)? I've never heard of it. "futures" to me are futures contracts in a trading environment (that's the industry I work in). No matter how well known the term is in the environment where it's used today you have to be sensitive to other meanings of the term. Skip
On Fri, Mar 5, 2010 at 11:56 AM, <skip@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 should be adopting things that Jesse> are common, and found elsewhere and then renaming them.
Perhaps, but is it a common term for Python programmers (or the target population for Python)? I've never heard of it. "futures" to me are futures contracts in a trading environment (that's the industry I work in). No matter how well known the term is in the environment where it's used today you have to be sensitive to other meanings of the term.
It's a common programming term. I don't think we should make a new name - I mean, how many different names for green threads / coroutines or "flavors" of those concepts are out there because someone painted the bike shed a different color? I mean, there's prior art here: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html jesse
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnoller@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 "Future". Why not name your module "concurrent"? That would eliminate the confusion with "from __future__". I don't see a problem with keeping the class name. Plus, a "concurrent" module might be useful for things other than Futures, in the future. ;-) Just my 0.02 cents, -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnoller@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 "Future".
Why not name your module "concurrent"? That would eliminate the confusion with "from __future__". I don't see a problem with keeping the class name.
Plus, a "concurrent" module might be useful for things other than Futures, in the future. ;-)
Brian's module is named futures; I am +1'ing his proposal, and also suggesting we put it under concurrent/ package name. This means you would do the following: from concurrent import futures and in the future: from concurrent import pool And so on.
On Fri, Mar 5, 2010 at 9:55 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnoller@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 "Future".
Why not name your module "concurrent"? That would eliminate the confusion with "from __future__". I don't see a problem with keeping the class name.
Plus, a "concurrent" module might be useful for things other than Futures, in the future. ;-)
Brian's module is named futures; I am +1'ing his proposal, and also suggesting we put it under concurrent/ package name. This means you would do the following:
from concurrent import futures
and in the future: from concurrent import pool
And so on.
"Future" is a pretty standard CS term for this concept (as noted "promise" is another), and it wasn't invented by Java. I am not worried at all about confusion with __future__ (which is after all surrounded by dunders and only appears in one specific context). FWIW, there are two different ways of designing the API for such a concept. In one, the "future" or "promise" object masquerades as an instance of the eventual result, like a proxy, and accessing any attribute would block until the result is available. I don't like this design much; the masquerading is never perfect, and attribute accesses become risks of exceptions related to the promised work. In the other design, which this PEP proposes, there is an explicit call to get the value, which blocks as needed. I found a wikipedia article (http://en.wikipedia.org/wiki/Futures_and_promises#Implicit_vs_explicit) that calls the former "implicit" and the latter "explicit". According to this article, the term "promise" was coined slightly older (by a year or so). I have no strong preference for either term; I suspect that if this were the only objection to the PEP Brian would be happy to rename futures to promises. -- --Guido van Rossum (python.org/~guido)
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 article is not very helpful on the implicit vs. explicit distinction. As far as I can tell from it, that distinction isn't really attached to "future" vs "promise." The only distinction the article described was in the context of the Alice language, where a future = promise (read-only) plus resolver (mutator). IMO that's not a compelling reason for adopting "future" in Python.
On Fri, Mar 5, 2010 at 9:47 PM, Stephen J. Turnbull <stephen@xemacs.org> 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 something I don't get from you now, but you will give me later.
The wikipedia article is not very helpful on the implicit vs. explicit distinction. As far as I can tell from it, that distinction isn't really attached to "future" vs "promise." The only distinction the article described was in the context of the Alice language, where a future = promise (read-only) plus resolver (mutator). IMO that's not a compelling reason for adopting "future" in Python.
It seems like a good idea to follow the choice other languages have used for the name (if they tend to agree) regardless of whether the evil Java followed it too. So let's take a poll: Io: Uses "future" to refer to the implicit kind (http://www.iolanguage.com/scm/io/docs/IoGuide.html#Concurrency-Futures) Alice ML: Uses "future" to refer to the implicit kind, and "promise" to refer to a handle that can fill in the future (http://www.ps.uni-saarland.de/alice/manual/futures.html) Java: Uses "future" to refer to the explicit kind. (http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html) AmbientTalk: Uses "future" to refer to something more like a deferred: you register callbacks to run when the future is resolved. (http://soft.vub.ac.be/amop/at/tutorial/actors#futures) C++0x: Uses "future" to refer to the explicit kind; "promise" similarly to AliceML, and "packaged_task" to get a future from a callable. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf section 30.6) E: Uses "promise" to refer to the implicit kind, and "resolver" to refer to a handle that can fill in the promise. (http://wiki.erights.org/wiki/Promise) Oz: A "future" is a read-only logic variable. I'm not entirely sure what that means. (http://www.mozart-oz.org/documentation/dstutorial/node2.html#label61) PLT Scheme: Uses "future" to refer to the explicit kind. (http://docs.plt-scheme.org/futures/index.html) C#: Uses "Task<TResult>" to refer to the explicit kind. (http://msdn.microsoft.com/en-us/library/dd321424(VS.100).aspx) Id, from 1991: Used "I-structure" to refer to the implicit kind. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.4920) Scala: Uses "Future" to refer to the explicit kind. (http://www.scala-lang.org/docu/files/api/scala/actors/Actor.html#%21%21%28An...) What languages did I miss? From this list, "future" seems to be the most popular choice, and it doesn't seem to distinguish between the implicit and explicit kinds. Jeffrey
On Fri, Mar 5, 2010 at 09:55, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnoller@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 "Future".
Why not name your module "concurrent"? That would eliminate the confusion with "from __future__". I don't see a problem with keeping the class name.
Plus, a "concurrent" module might be useful for things other than Futures, in the future. ;-)
Brian's module is named futures; I am +1'ing his proposal, and also suggesting we put it under concurrent/ package name. This means you would do the following:
from concurrent import futures
and in the future: from concurrent import pool
And so on.
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 multiprocessing into the concurrent namespace, are you thinking like concurrent.multiprocessing? I guess I am just trying to figure out what the abstraction is you are after in the package namespace. -Brett
On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon <brett@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 multiprocessing into the concurrent namespace, are you thinking like concurrent.multiprocessing? I guess I am just trying to figure out what the abstraction is you are after in the package namespace. -Brett
My goal would be to put futures into a "concurrent" package - as it is an abstraction that allows for threads, and processes to be used. By default; I don't think we'd make a guess based on the platform, but rather pick a sane default (such as threads). After that; I would begin to remove chunks of multiprocessing (such as pool) and adapt it to the same type of "pick threads or processes" that futures uses. For example: from concurrent import Pool x = Pool(4, worker_primitive=Thread()) And so on. The end-goal would be to make concurrent.* a package containing common abstractions/patterns which can use threads or processes interchangeably. jesse
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 years, have never touched Java, and the only times I've seen its effect in Python I have been unimpressed (logging and unittest). Google for "future". The Java doc is aways down on the front page. Now Google for "futures". It's nowhere to be found. As far as I can tell, all but one hit on the first page are for my definition of "futures". At the bottom of the page the "searches related to _futures_" are all related to trading futures or other derivatives except one. That appears to be related to the LPGA futures tour. Java and its definition of the term is nowhere to be found. I suppose you can argue that it should be called "future". I still contend that the name is *not* intuitive, no matter how well known it happens to be within the Java world. Don't name it "futures" though. That has nothing to do with common definitions of the term. Skip
skip@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 professional programmer for about 30 years, have never touched Java, and the only times I've seen its effect in Python I have been unimpressed (logging and unittest).
Google for "future". The Java doc is aways down on the front page. Now Google for "futures". It's nowhere to be found. As far as I can tell, all but one hit on the first page are for my definition of "futures". At the bottom of the page the "searches related to _futures_" are all related to trading futures or other derivatives except one. That appears to be related to the LPGA futures tour. Java and its definition of the term is nowhere to be found.
This term, the "future", has been in use at least since 1985, even if the Web hasn't, and even if Google can't seem to separate this use from drivel about stock trading. See Halstead's 1985 TOPLAS paper on MultiLisp. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.1841 Bill
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
Another common term for this is a "promise". -- Curt Hagenlocher curt@hagenlocher.org
On 05:06 pm, curt@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
Another common term for this is a "promise".
Promises aren't exactly the same. This would be a particularly bad name to apply here. Jean-Paul
On Fri, Mar 5, 2010 at 10:30 AM, <exarkun@twistedmatrix.com> wrote:
On 05:06 pm, curt@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
Another common term for this is a "promise".
Promises aren't exactly the same. This would be a particularly bad name to apply here.
Please explain. Even the Wikipedia article (http://en.wikipedia.org/wiki/Futures_and_promises), despite promising to explain the difference, didn't explain it. -- --Guido van Rossum (python.org/~guido)
On 07:10 pm, guido@python.org wrote:
On Fri, Mar 5, 2010 at 10:30 AM, <exarkun@twistedmatrix.com> wrote:
On 05:06 pm, curt@hagenlocher.org wrote:
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
Another common term for this is a "promise".
Promises aren't exactly the same. �This would be a particularly bad name to apply here.
Please explain. Even the Wikipedia article (http://en.wikipedia.org/wiki/Futures_and_promises), despite promising to explain the difference, didn't explain it.
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 this. Though the difference is mainly one of API, it turns out to make a significant difference in what you can accomplish. Promises are much more amenable to the pipelining optimization, for example. They're also much harder to implement in Python without core language changes. Jean-Paul
On Fri, Mar 5, 2010 at 12:18 PM, <exarkun@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 promises look like this.
Fair enough, though the article confuses the matter by using the words more or less interchangeably.
Though the difference is mainly one of API, it turns out to make a significant difference in what you can accomplish. Promises are much more amenable to the pipelining optimization, for example. They're also much harder to implement in Python without core language changes.
That's why implicit futures (by any name) aren't on the table. -- --Guido van Rossum (python.org/~guido)
exarkun@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 this.
*sigh* All I can say is "it's a damned shame that there are no native speakers of English working in computer science."<wink> 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". (Especially when wearing my Professional Economist sweatshirt. :-)
"Stephen J. Turnbull" <stephen@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 issue that Python *already* uses this term for the name of a module with a totally unrelated purpose; the ‘__future__’ pseudo-module? That alone seems a pretty strong reason to avoid the word “future” (singular or plural) for some other module name. -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard Stallman | _o__) | Ben Finney
On Mar 6, 2010, at 5:47 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
"Stephen J. Turnbull" <stephen@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 issue that Python *already* uses this term for the name of a module with a totally unrelated purpose; the ‘__future__’ pseudo-module?
That alone seems a pretty strong reason to avoid the word “future” (singular or plural) for some other module name.
Yes, they have, and putting it in a sub namespace has also come up. In the thread.
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 __builtin__/__builtins__ confusion. Skip
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
- -1 to the name from me as well: it isn't "scoped" properly to make it clear what the module is about. If they were inside a pacakge named 'concurrency' or some such (as hinted by Jesse Noller, I think), the clash would go away. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuRapAACgkQ+gerLs4ltQ7dBwCfRmMuq6X9VE8usYgSScXEA1D0 1PsAoI8MR5hjPjq9C7MFPTZhcO/T+NM4 =7wpK -----END PGP SIGNATURE-----
On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
- -1 to the name from me as well: it isn't "scoped" properly to make it clear what the module is about. If they were inside a pacakge named 'concurrency' or some such (as hinted by Jesse Noller, I think), the clash would go away.
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. Jesse
On Fri, Mar 5, 2010 at 1:42 PM, Jesse Noller <jnoller@gmail.com> wrote:
On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Noller wrote:
On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them.
- -1 to the name from me as well: it isn't "scoped" properly to make it clear what the module is about. If they were inside a pacakge named 'concurrency' or some such (as hinted by Jesse Noller, I think), the clash would go away.
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.
A simple renaming of futures to concurrency.futures seems easy enough to swallow. (Though I haven't kept track of what other modules the PEP proposes.) -- --Guido van Rossum (python.org/~guido)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote: > On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver <tseaver@palladion.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jesse Noller wrote: >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> <daniel@stutzbachenterprises.com> wrote: >>>> On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@sweetapp.com> 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 >>> languages. I don't think we should be adopting things that are common, >>> and found elsewhere and then renaming them. >> - -1 to the name from me as well: it isn't "scoped" properly to make it >> clear what the module is about. If they were inside a pacakge named >> 'concurrency' or some such (as hinted by Jesse Noller, I think), the >> clash would go away. > > 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. I'm just expressiong a preference for scoping the name, and don't want to preempt the process. If your proposed work on factoring common stuff out of multiprocessing would sit in the same conceptual space, then sharing the package name seems like a good plan to me. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuRj74ACgkQ+gerLs4ltQ5RNACeKYku88A9PBuQR46QTl7GrEwo mPEAoLdYyi+TLGYFw4SRAIM8zBsNvwxr =iPkb -----END PGP SIGNATURE-----
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 concurrent.futures name or you can draft a more complete PEP that describes what other functionality should live in the concurrent package. Cheers, Brian
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 this PEP to propose the concurrent.futures name or you can draft a more complete PEP that describes what other functionality should live in the concurrent package.
I think a "concurrent.futures" name works - it gives the scoping desired by the folks with an finance background and gives us a bucket for future thread/process agnostic concurrency tools (such as a pools and message queues). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan <brian@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?
I thought about that but this discussion is spread over many threads and many months. Cheers, Brian
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 <brian@sweetapp.com <mailto:brian@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?
I thoug ht about that but this discussion is spread over many threads and many months.
This is pretty typical. I would say just that, and link to the first. "This PEP was discussed over many months in many threads in the stdlib-sig list. The first was .... . Python-dev discussion occured in <this thread>. tjr
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 <brian@sweetapp.com <mailto:brian@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?
I thoug ht about that but this discussion is spread over many threads and many months.
This is pretty typical. I would say just that, and link to the first. "This PEP was discussed over many months in many threads in the stdlib-sig list. The first was .... . Python-dev discussion occured in <this thread>.
I'll add that. Cheers, Brian
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:03, Brian Quinlan <brian@sweetapp.com> 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/process pools and work queues.
The package has been discussed on stdlib-sig but now I'd like this group's feedback.
The PEP lives here: http://python.org/dev/peps/pep-3148/
Here are two examples to whet your appetites:
"""Determine if several numbers are prime.""" import futures import math
PRIMES = [ 112272535095293, 112582705942171, 112272535095293, 115280095190773, 115797848077099, 1099726899285419]
def is_prime(n): if n % 2 == 0: return False
sqrt_n = int(math.floor(math.sqrt(n))) for i in range(3, sqrt_n + 1, 2): if n % i == 0: return False return True
# Uses as many CPUs as your machine has. with futures.ProcessPoolExecutor() as executor: for number, is_prime in zip(PRIMES, executor.map(is_prime, PRIMES)): print('%d is prime: %s' % (number, is_prime))
"""Print out the size of the home pages of various new sites (and Fox News).""" import futures import urllib.request
URLS = ['http://www.foxnews.com/', 'http://www.cnn.com/', 'http://europe.wsj.com/', 'http://www.bbc.co.uk/', 'http://some-made-up-domain.com/']
def load_url(url, timeout): return urllib.request.urlopen(url, timeout=timeout).read()
with futures.ThreadPoolExecutor(max_workers=5) as executor: # Create a future for each URL load. future_to_url = dict((executor.submit(load_url, url, 60), url) for url in URLS)
# Iterate over the futures in the order that they complete. for future in futures.as_completed(future_to_url): url = future_to_url[future] if future.exception() is not None: print('%r generated an exception: %s' % (url, future.exception())) else: print('%r page is %d bytes' % (url, len(future.result())))
Cheers, Brian _______________________________________________ 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/brett%40python.org
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, return_when=ALL_COMPLETED)``?
Hi Brett, 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. Cheers, Brian
On Thu, Mar 4, 2010 at 22:03, Brian Quinlan <brian@sweetapp.com> 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/process pools and work queues.
The package has been discussed on stdlib-sig but now I'd like this group's feedback.
The PEP lives here: http://python.org/dev/peps/pep-3148/
Here are two examples to whet your appetites:
"""Determine if several numbers are prime.""" import futures import math
PRIMES = [ 112272535095293, 112582705942171, 112272535095293, 115280095190773, 115797848077099, 1099726899285419]
def is_prime(n): if n % 2 == 0: return False
sqrt_n = int(math.floor(math.sqrt(n))) for i in range(3, sqrt_n + 1, 2): if n % i == 0: return False return True
# Uses as many CPUs as your machine has. with futures.ProcessPoolExecutor() as executor: for number, is_prime in zip(PRIMES, executor.map(is_prime, PRIMES)): print('%d is prime: %s' % (number, is_prime))
"""Print out the size of the home pages of various new sites (and Fox News).""" import futures import urllib.request
URLS = ['http://www.foxnews.com/', 'http://www.cnn.com/', 'http://europe.wsj.com/', 'http://www.bbc.co.uk/', 'http://some-made-up-domain.com/']
def load_url(url, timeout): return urllib.request.urlopen(url, timeout=timeout).read()
with futures.ThreadPoolExecutor(max_workers=5) as executor: # Create a future for each URL load. future_to_url = dict((executor.submit(load_url, url, 60), url) for url in URLS)
# Iterate over the futures in the order that they complete. for future in futures.as_completed(future_to_url): url = future_to_url[future] if future.exception() is not None: print('%r generated an exception: %s' % (url,
future.exception())) else: print('%r page is %d bytes' % (url, len(future.result())))
Cheers, Brian _______________________________________________ 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/brett%40python.org
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 guaranteed part of the API. There isn't necessarily any need to enforce that, though. -- Greg
Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan <brian@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 return False, otherwise the call will be cancelled and the method will return True.
I think it shouldn't return anything, and raise an exception if cancelling failed. It is really an error condition, and ignoring the result doesn't seem right.
Future.running()
Return True if the call is currently being executed and cannot be cancelled.
Future.done()
Return True if the call was successfully cancelled or finished running.
These don't really make sense since the future is executing concurrently. By the time the result is returned, it can already be wrong. I advocate removing those two methods.
The following Future methods are meant for use in unit tests and Executor implementations.
Their names should then be preceded by an underscore '_'. We don't want people to think they are public APIs and start relying on them.
wait(fs, timeout=None, return_when=ALL_COMPLETED) [...]
This method should always be called using keyword arguments
I don't think this is right. Keyword arguments are nice, but mandating them too often is IMO a nuisance (after all, it makes things longer to type and requires you to remember the exact parameter names). Especially when the method only takes at most 3 arguments. IMO, keyword-only arguments are mostly useful when there are a lot of positional arguments before, and you want to help the user use the right calling signature. Regards Antoine.
On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan <brian@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 return False, otherwise the call will be cancelled and the method will return True.
I think it shouldn't return anything, and raise an exception if cancelling failed. It is really an error condition, and ignoring the result doesn't seem right.
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 through). Would calling the method try_cancel() work better?
Future.running()
Return True if the call is currently being executed and cannot be cancelled.
Future.done()
Return True if the call was successfully cancelled or finished running.
These don't really make sense since the future is executing concurrently. By the time the result is returned, it can already be wrong. I advocate removing those two methods.
"done()" can only be wrong in one direction though. If it returns True, it'll never again return False, which can be useful (although perhaps only for polling, which might be an argument for removing it anyway). "running()" becomes True and then False again, so I agree with your objection. A "started()" function would only go from False to True once. Maybe that's a better function? Jeffrey
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 through).
I think it's your C++ background showing. In Python philosophy, there's no particlular connection between whether something can be tested for and whether it should raise an exception. 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. -- Greg
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 is generally a best effort activity - having to wrap it an exception handler would be annoying. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan <brian@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 return False, otherwise the call will be cancelled and the method will return True.
I think it shouldn't return anything, and raise an exception if cancelling failed. It is really an error condition, and ignoring the result doesn't seem right.
In my experience with futures, canceling them is a best-effort optimization that people use when another future fails. For example: futures = [executor.submit(CopyDirectory, src, dest) for dest in ...] finished, unfinished = wait(futures, return_when=FIRST_EXCEPTION) # If there are unfinished futures then there must have been a failure for f in unfinished: # No reason to waste bandwidth copying files if the operation has already failed. f.cancel() for f in finished(): if f.exception(): raise f.exception()
Future.running()
Return True if the call is currently being executed and cannot be cancelled.
Future.done()
Return True if the call was successfully cancelled or finished running.
These don't really make sense since the future is executing concurrently. By the time the result is returned, it can already be wrong. I advocate removing those two methods.
There methods are useful for logging - by displaying the count of pending, running and completed futures you can estimate the progress of the system.
The following Future methods are meant for use in unit tests and Executor implementations.
Their names should then be preceded by an underscore '_'. We don't want people to think they are public APIs and start relying on them.
Actually, as discussed on the stdlib-sig, these methods are designed to make it possible for users to implement their own Executors so we'll have keep the interface stable.
wait(fs, timeout=None, return_when=ALL_COMPLETED) [...]
This method should always be called using keyword arguments
I don't think this is right. Keyword arguments are nice, but mandating them too often is IMO a nuisance (after all, it makes things longer to type and requires you to remember the exact parameter names). Especially when the method only takes at most 3 arguments.
IMO, keyword-only arguments are mostly useful when there are a lot of positional arguments before, and you want to help the user use the right calling signature.
I agree, I'll change this. Cheers, Brian
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/process pools and work queues.
The package has been discussed on stdlib-sig but now I'd like this group's feedback.
My immediate reaction is that this would be a lot more useful if it built on an API for coroutine yielding/interaction, similar to what's in say, Eventlet. That would seem to make it easier to write synchronous-looking code that operates on futures, and allow futures to be composed more cleanly. ISTM that if futures were standardized before a coroutine API, it would lead to effective orphaning ala what happened with asyncore, especially since the new library is, well, new. I'm somewhat concerned that, as described, the proposed API adds little over what's relatively easy to do with a mature coroutine framework like Eventlet, 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. As far as naming goes, Twisted uses the term "Deferred" for this concept (and also has a very mature API for handling them). And speaking of Twisted, it seems to me that the PEP would be much improved in general by learning from some of the lessons of other systems. I don't think that Java's example is really the best one to follow in this instance, compared to the many existing async frameworks that have Python-specific experience and APIs to learn from. Or, to put it another way, something that worries me about this PEP is that nearly all of its Python-related citations are for *discussions* of futures, with the only previous Python implementation cited being a crude sketch of a cookbook recipe. The PEP also doesn't address questions of interoperability with existing solutions, compare features with them, or even so much as say, "There are other production implementations of this concept in Python, but we are going to pretend they don't exist." ;-)
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby <pje@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 an event loop.
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 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 use it. -- Greg
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 the *last* thing we need!
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 use it.
Wouldn't it have to be the Tcl event loop then? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Sat, Mar 6, 2010 at 5:38 PM, Michael Foord <fuzzyman@voidspace.org.uk>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 use it.
Wouldn't it have to be the Tcl event loop then?
I image he means a standardized Abstract Base Class, which each GUI toolkit would subclass. That's more or less how Twisted's "reactors" work. That way non-GUI async code can just use the ABC and not worry about what event loop is running underneath (be it TCL, GTK, or just poll()). -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
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
participants (20)
-
Antoine Pitrou -
Ben Finney -
Bill Janssen -
Brett Cannon -
Brian Quinlan -
Calvin Spealman -
Curt Hagenlocher -
Daniel Stutzbach -
exarkun＠twistedmatrix.com -
Greg Ewing -
Guido van Rossum -
Jeffrey Yasskin -
Jesse Noller -
Michael Foord -
Nick Coghlan -
Phillip J. Eby -
skip＠pobox.com -
Stephen J. Turnbull -
Terry Reedy -
Tres Seaver