On Mon, Jul 12, 2010 at 02:13, Jesse Noller jnol...@gmail.com wrote:
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org
wrote:
[snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on this PEP, I hereby appoint you chair of the
Hi I learned about the futures PEP only today. I saw the example on
http://code.google.com/p/pythonfutures/
One thing that worries me is that this approach seems to bypass the
usual exception handling mechanism of Python. In particular I'm
wondering why you have to do things like:
if
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
malsb...@gmail.com wrote:
This reminds me a lot of how things are done in C but it's not very
pythonic. Wouldn't it be possible and nicer to raise the exception --
if there was one inside the asynchronous job -- when the result of the
On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
That's what actually happens, so you can code it either way
That's great! None of the examples I found used the pythonic
exception style, that's why I assumed that checking
On 13 Jul 2010, at 00:59, Titus von der Malsburg wrote:
On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
That's what actually happens, so you can code it either way
That's great! None of the examples I found used the
Titus von der Malsburg wrote:
None of the examples I found used the pythonic
exception style, that's why I assumed that checking the return value
is the only possibility. Reading the PEP carefully would have helped.
:-)
I had to read the pep fairly carefully before I noticed
this too, so
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org wrote:
[snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on this PEP, I hereby appoint you chair of the
approval process for this PEP. That basically means that when you
think it's
2010/7/11 Jesse Noller jnol...@gmail.com:
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org wrote:
[snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on this PEP, I hereby appoint you chair of the
approval process for this PEP. That
On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson benja...@python.org wrote:
2010/7/11 Jesse Noller jnol...@gmail.com:
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org wrote:
[snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on
2010/7/11 Jesse Noller jnol...@gmail.com:
On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson benja...@python.org
wrote:
2010/7/11 Jesse Noller jnol...@gmail.com:
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org wrote:
[snip]
Great points Jesse! Since I really don't have
On May 28, 2010, at 11:31 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 29/05/10 10:19, Jesse Noller wrote:
In my opinion, it is high time for the std lib to pay more
attention to
the final Zen:
Namespaces are one honking great idea -- let's do more of those!
Yes, your suggestion for
On 29/05/10 22:46, Jesse Noller wrote:
On May 28, 2010, at 11:31 PM, Nick Coghlan ncogh...@gmail.com wrote:
Since this topic keeps coming up, some reasoning along these lines
should go into PEP 3148.
I'll type something up this weekend and shoot it to Brian for inclusion.
I was hoping to be
On Fri, May 28, 2010 at 17:12, Steven D'Aprano st...@pearwood.info wrote:
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have
missed it: we already have a __future__ module, as in
from __future__ import with_statement
and
On May 28, 2010, at 1:39 PM, Scott Dial wrote:
On 5/27/2010 4:13 AM, Brian Quinlan wrote:
On 27 May 2010, at 17:53, Floris Bruynooghe wrote:
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the
Brian Quinlan brian at sweetapp.com writes:
future is a computing science term of art, like thread. Anyway,
this has been discussed in the past and Guido was happy with the name.
I've not seen this mentioned, but on such a long thread I might have missed it:
we already have a __future__
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have
missed it: we already have a __future__ module, as in
from __future__ import with_statement
and to my mind, this is a potential point of confusion with the term
future.
Vinay Sajip wrote:
Brian Quinlan brian at sweetapp.com writes:
future is a computing science term of art, like thread. Anyway,
this has been discussed in the past and Guido was happy with the name.
I've not seen this mentioned, but on such a long thread I might have missed
it:
we
On May 28, 2010, at 8:12 PM, Steven D'Aprano st...@pearwood.info
wrote:
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have
missed it: we already have a __future__ module, as in
from __future__ import with_statement
On 29/05/10 10:19, Jesse Noller wrote:
In my opinion, it is high time for the std lib to pay more attention to
the final Zen:
Namespaces are one honking great idea -- let's do more of those!
Yes, your suggestion for how to move things is the way we would want to
do it, and in the back of my
Steven D'Aprano wrote:
I have suggested a way to move the existing concurrency stuff without
breaking backwards compatibility, and Terry Reedy asked if it would
work. I haven't seen any responses, either positive or negative.
For the record, my suggestion was:
for each concurrency modules:
On May 27, 2010, at 1:21 PM, Greg Ewing wrote:
On 27/05/10 12:04, Jesse Noller wrote:
Namespaces are
only a honking great idea if you actually let them do the job
they're designed for.
concurrent.* is the namespace, futures is the package within the
namespace - concurrent.futures is highly
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2. wait until the future finishes and then exit
I'd go for (1). I don't think it's unreasonable
On 27 May 2010, at 17:53, Floris Bruynooghe wrote:
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2. wait until the future finishes and then
On Thu, 27 May 2010 14:29:28 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
On 27/05/10 01:48, Nick Coghlan wrote:
I would say it is precisely that extra configurability which separates
the executor pools in the PEP implementation from more flexible general
purpose pools.
Wouldn't
On 27/05/10 12:48, Scott Dial wrote:
On 5/26/2010 8:03 PM, Nick Coghlan wrote:
On 27/05/10 02:27, Terry Reedy wrote:
I am suggesting that if we add a package, we do it right, from the
beginning.
This is a reasonable point of view, but I wouldn't want to hold up PEP
3148 over it (call it a +0
On 27/05/10 12:29, Greg Ewing wrote:
On 27/05/10 01:48, Nick Coghlan wrote:
I would say it is precisely that extra configurability which separates
the executor pools in the PEP implementation from more flexible general
purpose pools.
Wouldn't this be better addressed by adding the relevant
On 27/05/10 18:13, Brian Quinlan wrote:
On 27 May 2010, at 17:53, Floris Bruynooghe wrote:
I'm glad I'm not alone in preferring (1) tough.
Keep in mind that this library magic is consistent with the library
magic that the threading module does - unless the user sets
Thread.daemon to True,
On 27/05/10 10:29, Antoine Pitrou wrote:
On Thu, 27 May 2010 10:19:50 +1000
Nick Coghlanncogh...@gmail.com wrote:
futures.ThreadPoolExecutor would likely be refactored to inherit from
the mooted pool.ThreadPool.
There still doesn't seem to be reason to have two different thread pool
APIs,
On 28/05/10 02:16, Antoine Pitrou wrote:
On Fri, 28 May 2010 02:05:14 +1000
Nick Coghlanncogh...@gmail.com wrote:
Executors and thread pools are not the same thing.
I might create a thread pool for *anything*. An executor will always
have a specific execution model associated with it
Brian Quinlan wrote:
I think that the Executor suffix is a good indicator of the interface
being provided.
It's not usually considered necessary for the name of a
type to indicate its interface. We don't have 'listsequence'
and 'dictmapping' for example.
I think what bothers me most about
On 28 May 2010, at 09:18, Greg Ewing wrote:
Brian Quinlan wrote:
I think that the Executor suffix is a good indicator of the
interface being provided.
It's not usually considered necessary for the name of a
type to indicate its interface. We don't have 'listsequence'
and 'dictmapping' for
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan br...@sweetapp.com wrote:
Keep in mind that this library magic is consistent with the library magic
that the threading module does - unless the user sets Thread.daemon to True,
the interpreter does *not* exit until the thread does.
Is there a
On May 28, 2010, at 11:57 AM, Reid Kleckner wrote:
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan br...@sweetapp.com
wrote:
Keep in mind that this library magic is consistent with the library
magic
that the threading module does - unless the user sets Thread.daemon
to True,
the
On Thu, May 27, 2010 at 8:06 PM, Brian Quinlan br...@sweetapp.com wrote:
On May 28, 2010, at 11:57 AM, Reid Kleckner wrote:
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan br...@sweetapp.com wrote:
Keep in mind that this library magic is consistent with the library magic
that the threading
On 5/27/2010 4:13 AM, Brian Quinlan wrote:
On 27 May 2010, at 17:53, Floris Bruynooghe wrote:
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2.
On 28/05/10 09:52, Greg Ewing wrote:
Nick Coghlan wrote:
We can accept PEP 3148 by saying that we're happy to add the extra
namespace level purely for disambiguation purposes,
If that's the only rationale for the namespace, it makes it
sound like a kludge to work around a poor choice of
On Wed, May 26, 2010 at 06:22, Nick Coghlan ncogh...@gmail.com wrote:
- download a futures module from PyPI and live with the additional
dependency
Why would that be a problem?
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
On 26 May 2010 08:11, Lennart Regebro rege...@gmail.com wrote:
On Wed, May 26, 2010 at 06:22, Nick Coghlan ncogh...@gmail.com wrote:
- download a futures module from PyPI and live with the additional
dependency
Why would that be a problem?
That has been hashed out repeatedly on this and
On Wed, 26 May 2010 09:54:13 +1000
Nick Coghlan ncogh...@gmail.com wrote:
What I would question here is what other things will be part
of the concurrent package, and who will implement them. Are there
plans for that? (or even tracker issues open?)
I'm not sure it is called out
On May 24, 2010, at 5:36 AM, Brian Quinlan wrote:
On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote:
On May 23, 2010, at 2:37 AM, Brian Quinlan wrote:
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
ProcessPoolExecutor has the same serialization perils that multiprocessing
does. My
On Wed, May 26, 2010 at 09:37, Paul Moore p.f.mo...@gmail.com wrote:
It seems to me that if you've experienced the sort of culture that
makes it a problem,
Ah, it's a culture problem.
In a heterogenous world, every action will benefit some and hurt some.
Another arbitrary corporate ruleset
On May 26, 2010, at 3:37 AM, Paul Moore wrote:
On 26 May 2010 08:11, Lennart Regebro rege...@gmail.com wrote:
On Wed, May 26, 2010 at 06:22, Nick Coghlan ncogh...@gmail.com wrote:
- download a futures module from PyPI and live with the additional
dependency
Why would that be a problem?
On 26 May 2010, at 18:44, Stephen J. Turnbull wrote:
Nick Coghlan writes:
On 26/05/10 13:51, Stephen J. Turnbull wrote:
People have been asking what's special about this module, to
violate
the BCP principle? There's nothing special about the fact that
several people would use a robust
On 26 May 2010, at 18:09, Glyph Lefkowitz wrote:
On May 24, 2010, at 5:36 AM, Brian Quinlan wrote:
On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote:
On May 23, 2010, at 2:37 AM, Brian Quinlan wrote:
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
ProcessPoolExecutor has the same
On May 26, 2010, at 4:55 AM, Brian Quinlan wrote:
I said exactly the opposite of what I meant: futures don't need a reference
to the invoker.
Indeed they don't, and they really shouldn't have one. If I wrote that they
did, then it was an error.
... and that appears to be it! Thank you
On Wed, 26 May 2010 04:25:18 -0400
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
In other words, while I kinda-sorta buy Brian's argument that having this
module in easy reach
will motivate more people to use a standard, tested idiom for
parallelization, I *don't* think
that the stdlib
On Wed, 26 May 2010 07:39:15 pm Antoine Pitrou wrote:
On Wed, 26 May 2010 04:25:18 -0400
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
In other words, while I kinda-sorta buy Brian's argument that
having this module in easy reach will motivate more people to use a
standard, tested idiom
Having read through the PEP again, here are my thoughts.
* I'm bothered by the term future. To my mind, it's
too long on cleverness and too short on explanativeness.
I think that the standard library is no place for
cuteness of naming. The name of a stdlib module should
reflect its
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano st...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such people to the exclusion of all else, but these folks are
stakeholders too, and their wants and needs are just as worthy as the
wants
On May 26, 2010, at 8:57 PM, Greg Ewing wrote:
Having read through the PEP again, here are my thoughts.
* I'm bothered by the term future. To my mind, it's
too long on cleverness and too short on explanativeness.
I think that the standard library is no place for
cuteness of naming. The name
On Wed, 26 May 2010 08:57:15 pm Greg Ewing wrote:
* I'm bothered by the term future. To my mind, it's
too long on cleverness and too short on explanativeness.
Futures is a standard term in computer science which has been around
for 33 years.
http://en.wikipedia.org/wiki/Futures_and_promises
Hi
On Sun, May 23, 2010 at 10:47:08AM +1000, Brian Quinlan wrote:
Jesse, the designated pronouncer for this PEP, has decided to keep
discussion open for a few more days.
So fire away!
In thread.py the module automatically registers a handler with atexit.
I don't think I'm alone in thinking
On 26 May 2010 11:56, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano st...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such people to the exclusion of all else, but these folks are
stakeholders
On Wed, May 26, 2010 at 8:19 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 26 May 2010 11:56, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano st...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such
On 26/05/10 20:56, Antoine Pitrou wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Apranost...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such people to the exclusion of all else, but these folks are
stakeholders too, and their wants and
On 26/05/2010 13:19, Paul Moore wrote:
On 26 May 2010 11:56, Antoine Pitrousolip...@pitrou.net wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Apranost...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such people to the exclusion
On 26 May 2010, at 22:06, Floris Bruynooghe wrote:
Hi
On Sun, May 23, 2010 at 10:47:08AM +1000, Brian Quinlan wrote:
Jesse, the designated pronouncer for this PEP, has decided to keep
discussion open for a few more days.
So fire away!
In thread.py the module automatically registers a
On 26/05/10 17:38, Antoine Pitrou wrote:
On Wed, 26 May 2010 09:54:13 +1000
Nick Coghlanncogh...@gmail.com wrote:
What I would question here is what other things will be part
of the concurrent package, and who will implement them. Are there
plans for that? (or even tracker issues open?)
I'm
On 26/05/10 20:57, Greg Ewing wrote:
Having read through the PEP again, here are my thoughts.
* It seems unnecessarily verbose to tack Executor
onto the end of every Executor subclass. They could
simply be called ThreadPool and ProcessPool without
losing anything.
We would lose the ability to
On Wed, 26 May 2010 22:32:33 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Ha, I'm a bit surprised. Isn't it what futures already provides?
(except that for some reason it insists on the SomeExecutor naming
scheme)
http://www.python.org/dev/peps/pep-3148/#processpoolexecutor
Not really
On Wed, May 26, 2010 at 8:42 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 26/05/10 20:57, Greg Ewing wrote:
Having read through the PEP again, here are my thoughts.
* It seems unnecessarily verbose to tack Executor
onto the end of every Executor subclass. They could
simply be called
On 26 May 2010, at 22:42, Nick Coghlan wrote:
On 26/05/10 20:57, Greg Ewing wrote:
Having read through the PEP again, here are my thoughts.
* It seems unnecessarily verbose to tack Executor
onto the end of every Executor subclass. They could
simply be called ThreadPool and ProcessPool without
On Wed, May 26, 2010 at 9:01 AM, Brian Quinlan br...@sweetapp.com wrote:
On 26 May 2010, at 22:42, Nick Coghlan wrote:
On 26/05/10 20:57, Greg Ewing wrote:
Having read through the PEP again, here are my thoughts.
* It seems unnecessarily verbose to tack Executor
onto the end of every
On 26 May 2010, at 22:50, Antoine Pitrou wrote:
On Wed, 26 May 2010 22:32:33 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Ha, I'm a bit surprised. Isn't it what futures already provides?
(except that for some reason it insists on the SomeExecutor naming
scheme)
On 26/05/10 23:01, Brian Quinlan wrote:
_thread, threading, Queue and multiprocessing do likely belong here,
but moving them isn't likely to be worth the pain. Does it help to
know that at least Jesse and I (and probably others) would like to see
concurrent.pool added eventually with robust
On 26/05/10 23:29, Brian Quinlan wrote:
On 26 May 2010, at 22:50, Antoine Pitrou wrote:
I think I'm a bit ignorant, but how is the Executor abstraction (and
its proposed implementations) not generic enough? You have a pool,
submit one or several tasks, and can either repeatedly poll for
On Wed, May 26, 2010 at 6:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano st...@pearwood.info wrote:
I'm not saying that Python-Dev should bend over backwards to accommodate
such people to the exclusion of all else, but these folks are
On 26/05/10 20:57, Greg Ewing wrote:
(More generally, I'm inclined to think that introducing
a namespace package for a category of modules having
existing members in the stdlib is an anti-pattern,
As a user, I agree with this.
unless it's done during the kind of namespace refactoring
On Wed, May 26, 2010 at 3:57 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Having read through the PEP again, here are my thoughts.
* I'm bothered by the term future. To my mind, it's
too long on cleverness and too short on explanativeness.
I think that the standard library is no place
Brian Quinlan wrote:
I think that Jesse was planning to add some functionality to this
namespace.
Even if that happens, the existing threading and multiprocessing
modules would remain outside of it.
You could have general thread pools that aren't related to executors
Yes, but it should
On 27/05/10 02:27, Terry Reedy wrote:
I am suggesting that if we add a package, we do it right, from the
beginning.
This is a reasonable point of view, but I wouldn't want to hold up PEP
3148 over it (call it a +0 for the idea in general, but a -1 for linking
it to the acceptance of PEP
On Wed, May 26, 2010 at 7:36 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Brian Quinlan wrote:
I think that Jesse was planning to add some functionality to this
namespace.
Even if that happens, the existing threading and multiprocessing
modules would remain outside of it.
Not
On Wed, May 26, 2010 at 8:03 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27/05/10 02:27, Terry Reedy wrote:
I am suggesting that if we add a package, we do it right, from the
beginning.
This is a reasonable point of view, but I wouldn't want to hold up PEP 3148
over it (call it a +0 for
On 27/05/10 09:36, Greg Ewing wrote:
Brian Quinlan wrote:
I think that Jesse was planning to add some functionality to this
namespace.
Even if that happens, the existing threading and multiprocessing
modules would remain outside of it.
You could have general thread pools that aren't
On Thu, 27 May 2010 10:19:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
futures.ThreadPoolExecutor would likely be refactored to inherit from
the mooted pool.ThreadPool.
There still doesn't seem to be reason to have two different thread pool
APIs, though. Shouldn't there be one obvious way
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2. wait until the future finishes and then exit
I'd go for (1). I don't think it's unreasonable to
expect a program that wants all its tasks to finish
to
Well... a middle ground certainly could exist; perhaps in the form of an
Extended Standard Library (community distribution), with simple
installation and management tools.
It could be blessed by python-dev and maintain a high standard (only well
established best-of-breed modules with a
On Wed, May 26, 2010 at 7:15 PM, Yaniv Aknin ya...@aknin.name wrote:
Well... a middle ground certainly could exist; perhaps in the form of an
Extended Standard Library (community distribution), with simple
installation and management tools.
I'm not sure about the 'installation and management
On 27/05/10 01:48, Nick Coghlan wrote:
I would say it is precisely that extra configurability which separates
the executor pools in the PEP implementation from more flexible general
purpose pools.
Wouldn't this be better addressed by adding the relevant
options to the futures pools, rather
On 5/26/2010 8:03 PM, Nick Coghlan wrote:
On 27/05/10 02:27, Terry Reedy wrote:
I am suggesting that if we add a package, we do it right, from the
beginning.
This is a reasonable point of view, but I wouldn't want to hold up PEP
3148 over it (call it a +0 for the idea in general, but a -1
On 27/05/10 12:04, Jesse Noller wrote:
Namespaces are
only a honking great idea if you actually let them do the job
they're designed for.
concurrent.* is the namespace, futures is the package within the
namespace - concurrent.futures is highly descriptive of the items
contained therein.
I
I don't think I'm understanding you correctly in that thread then, ISTM
that you're advocating better packaging systems as an alternative to
this. Would you mind clarifying?
Gladly.
In my mind, 'better packaging' is not just about something that will let
you do 'pypkg install foo' and
On 23/05/10 22:47, Antoine Pitrou wrote:
On Sun, 23 May 2010 08:34:22 -0400
Jesse Nollerjnol...@gmail.com wrote:
Brian has already agreed to name spacing it to concurrent.futures -
this means it will be a small part to a much larger concurrent.*
implementation ala Java.
What I would
On 23/05/10 21:56, Lennart Regebro wrote:
On Sun, May 23, 2010 at 13:29, Brian Quinlanbr...@sweetapp.com wrote:
Parts of it, yes. Just like I can replace most operations in os.path and
urlparse with a few lines of code.
Yeah, but parts of is not the question. I've read the PEP, and I do
On Tue, May 25, 2010 at 7:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 23/05/10 22:47, Antoine Pitrou wrote:
On Sun, 23 May 2010 08:34:22 -0400
Jesse Nollerjnol...@gmail.com wrote:
Brian has already agreed to name spacing it to concurrent.futures -
this means it will be a small part to
On Wed, May 26, 2010 at 02:10, Nick Coghlan ncogh...@gmail.com wrote:
Those that say just put it on PyPI may not recognise the additional ...
Just a note, so we don't get sidelined by misunderstandings: I don't
think anybody said that. ;-)
There are two issues here, one generic and one
On 26/05/10 12:29, Lennart Regebro wrote:
On Wed, May 26, 2010 at 02:10, Nick Coghlanncogh...@gmail.com wrote:
Those that say just put it on PyPI may not recognise the additional ...
Just a note, so we don't get sidelined by misunderstandings: I don't
think anybody said that. ;-)
Nah, that
On 24/05/10 20:46, Stephen J. Turnbull wrote:
Cameron Simpson writes:
There's a lot to be said for a robust implementation of a well defined
problem. Brian's module, had it been present and presuming it robust and
debugged, would have been quite welcome.
That, of course, is the
Nick Coghlan writes:
Those that say just put it on PyPI
Nobody is saying that, AFAICS. Nobody is saying that *some* futures
module shouldn't *eventually* go into the stdlib.
The question is whether *this* futures module should go into the
stdlib *now*. And it is clear that more time on PyPI
On 26/05/10 13:51, Stephen J. Turnbull wrote:
People have been asking what's special about this module, to violate
the BCP principle? There's nothing special about the fact that
several people would use a robust and debugged futures module if it
were in the stdlib. That's true of *every*
On 24 May 2010 03:58, Cameron Simpson c...@zip.com.au wrote:
I almost am Brian's hypothetical user. I've got a FuncMultiQueue that
accepts callables in synchronous and asynchronous modes for future
possibly-concurrent execution, just as the futures module does. I've
spent a _lot_ of time
Am 24.05.2010 01:51, schrieb Greg Ewing:
Brian Quinlan wrote:
The good news in this case is that the same API has been used
successfully in Java and C++ for years so it is unlikely that any major
changes will need to be made.
That doesn't follow. An API that's appropriate for Java or
On 2010-05-23, Terry Reedy wrote:
On 5/22/2010 8:06 PM, Jeffrey Yasskin wrote:
On Sat, May 22, 2010 at 4:12 PM, Brian Quinlanbr...@sweetapp.com wrote:
Rename executor = executer
-1 for consistency with Java.
-10 for 'executer'. As far as I can find out, it is a misspelling of
On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote:
On May 23, 2010, at 2:37 AM, Brian Quinlan wrote:
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
On May 22, 2010, at 8:47 PM, Brian Quinlan wrote:
Jesse, the designated pronouncer for this PEP, has decided to
keep discussion
Cameron Simpson writes:
There's a lot to be said for a robust implementation of a well defined
problem. Brian's module, had it been present and presuming it robust and
debugged, would have been quite welcome.
That, of course, is the consensus view, both in general and with
respect to this
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
On May 22, 2010, at 8:47 PM, Brian Quinlan wrote:
Jesse, the designated pronouncer for this PEP, has decided to keep
discussion open for a few more days.
So fire away!
As you wish!
I retract my request ;-)
The PEP should be
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan br...@sweetapp.com wrote:
snip
Finally, why isn't this just a module on PyPI? It doesn't seem like there's
any particular benefit to making this a stdlib module and going through the
whole PEP process - except maybe to prompt feedback like this
On May 23, 2010, at 7:15 PM, geremy condra wrote:
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan br...@sweetapp.com
wrote:
snip
Finally, why isn't this just a module on PyPI? It doesn't seem
like there's
any particular benefit to making this a stdlib module and going
through the
whole
On Sun, May 23, 2010 at 11:39, Brian Quinlan br...@sweetapp.com wrote:
This package eliminates the need to construct the boilerplate present in
many Python applications i.e. a thread or process pool, a work queue and
result queue. It also makes it easy to take an existing Python application
On May 23, 2010, at 7:54 PM, Lennart Regebro wrote:
On Sun, May 23, 2010 at 11:39, Brian Quinlan br...@sweetapp.com
wrote:
This package eliminates the need to construct the boilerplate
present in
many Python applications i.e. a thread or process pool, a work
queue and
result queue. It
1 - 100 of 143 matches
Mail list logo
