On Mon, Jul 12, 2010 at 02:13, Jesse Noller wrote:
> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum
> 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 PE
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 per
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 pyth
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 t
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
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
> future is access
2010/7/11 Jesse Noller :
> On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson
> wrote:
>> 2010/7/11 Jesse Noller :
>>> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum wrote:
>>> [snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on this PE
On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson wrote:
> 2010/7/11 Jesse Noller :
>> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum 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 th
2010/7/11 Jesse Noller :
> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum 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
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum 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 ready to be ap
On Fri, May 28, 2010 at 17:12, Steven D'Aprano 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 to m
On 29/05/10 22:46, Jesse Noller wrote:
On May 28, 2010, at 11:31 PM, Nick Coghlan 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 able to keep it out
On May 28, 2010, at 11:31 PM, Nick Coghlan 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 how to move things i
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 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
On May 28, 2010, at 8:12 PM, Steven D'Aprano
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 to my mind, this
Vinay Sajip wrote:
> Brian Quinlan 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:
> w
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
> "
Brian Quinlan 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__" modu
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 int
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 name.
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
On Thu, May 27, 2010 at 8:06 PM, Brian Quinlan wrote:
>
> On May 28, 2010, at 11:57 AM, Reid Kleckner wrote:
>
>> On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan wrote:
>>>
>>> Keep in mind that this library magic is consistent with the library magic
>>> that the threading module does - unless the
On May 28, 2010, at 11:57 AM, Reid Kleckner wrote:
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan
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
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan 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 compelling to make t
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 name.
--
Greg
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' fo
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/05/10 02:16, Antoine Pitrou wrote:
On Fri, 28 May 2010 02:05:14 +1000
Nick Coghlan 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 (whether it be called
futu
On Fri, 28 May 2010 02:05:14 +1000
Nick Coghlan 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 (whether it be called
> futures, as in this case, or runna
On 27/05/10 10:29, Antoine Pitrou wrote:
On Thu, 27 May 2010 10:19:50 +1000
Nick Coghlan 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 th
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, the
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
op
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 Thu, 27 May 2010 14:29:28 +1200
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 ad
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 exit
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 unr
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
>
> 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 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 wa
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
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 tha
On Wed, May 26, 2010 at 7:15 PM, Yaniv Aknin 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 tools' par
>
> 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 w
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 explic
On Thu, 27 May 2010 10:19:50 +1000
Nick Coghlan 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 to do it?
> I'
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 related
On Wed, May 26, 2010 at 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 i
On Wed, May 26, 2010 at 7:36 PM, 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.
Not entirely; once concurrent.
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 3148)
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 be
On Wed, May 26, 2010 at 3:57 AM, 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 nam
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
that
On Wed, May 26, 2010 at 6:56 AM, Antoine Pitrou wrote:
> On Wed, 26 May 2010 20:42:12 +1000
> Steven D'Aprano 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
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
completi
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 gener
On 26 May 2010, at 22:50, Antoine Pitrou wrote:
On Wed, 26 May 2010 22:32:33 +1000
Nick Coghlan 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/#proc
On Wed, May 26, 2010 at 9:01 AM, Brian Quinlan 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 Execu
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 withou
On Wed, May 26, 2010 at 8:42 AM, 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 an
On Wed, 26 May 2010 22:32:33 +1000
Nick Coghlan 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 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 26/05/10 17:38, Antoine Pitrou wrote:
On Wed, 26 May 2010 09:54:13 +1000
Nick Coghlan 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 c
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 handle
On 26/05/2010 13:19, Paul Moore wrote:
On 26 May 2010 11:56, Antoine Pitrou wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano 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
stakeho
On 26/05/10 20:56, Antoine Pitrou wrote:
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano 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 wort
On Wed, May 26, 2010 at 8:19 AM, Paul Moore wrote:
> On 26 May 2010 11:56, Antoine Pitrou wrote:
>> On Wed, 26 May 2010 20:42:12 +1000
>> Steven D'Aprano wrote:
>>>
>>> I'm not saying that Python-Dev should bend over backwards to accommodate
>>> such people to the exclusion of all else, but thes
On 26 May 2010 11:56, Antoine Pitrou wrote:
> On Wed, 26 May 2010 20:42:12 +1000
> Steven D'Aprano 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
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 thinki
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_prom
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 20:42:12 +1000
Steven D'Aprano 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 and needs of th
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 functionali
On Wed, 26 May 2010 07:39:15 pm Antoine Pitrou wrote:
> On Wed, 26 May 2010 04:25:18 -0400
>
> Glyph Lefkowitz 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 paralleliza
On Wed, 26 May 2010 04:25:18 -0400
Glyph Lefkowitz 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 should be expanded
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 f
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 ser
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
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 and debugged" futures module if it
> > wer
On May 26, 2010, at 3:37 AM, Paul Moore wrote:
> On 26 May 2010 08:11, Lennart Regebro wrote:
>> On Wed, May 26, 2010 at 06:22, Nick Coghlan wrote:
>>> - download a futures module from PyPI and live with the additional
>>> dependency
>>
>> Why would that be a problem?
>
> That has been hashed
On Wed, May 26, 2010 at 09:37, Paul Moore 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 could also mean you m
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
On Wed, 26 May 2010 09:54:13 +1000
Nick Coghlan 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 explicitly in th
On 26 May 2010 08:11, Lennart Regebro wrote:
> On Wed, May 26, 2010 at 06:22, Nick Coghlan 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 other lists. Can it
please be sti
On Wed, May 26, 2010 at 06:22, Nick Coghlan 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/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* mo
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 Py
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 c
On 26/05/10 12:29, Lennart Regebro wrote:
On Wed, May 26, 2010 at 02:10, Nick Coghlan 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 pseudo-quote was
On Wed, May 26, 2010 at 02:10, Nick Coghlan 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 specific:
Generic: Modu
On Tue, May 25, 2010 at 7:54 PM, Nick Coghlan wrote:
> On 23/05/10 22:47, Antoine Pitrou wrote:
>>
>> On Sun, 23 May 2010 08:34:22 -0400
>> Jesse Noller wrote:
>>>
>>> Brian has already agreed to name spacing it to "concurrent.futures" -
>>> this means it will be a small part to a much larger con
On 23/05/10 21:56, Lennart Regebro wrote:
On Sun, May 23, 2010 at 13:29, Brian Quinlan 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
*not* know how to imp
On 23/05/10 22:47, Antoine Pitrou wrote:
On Sun, 23 May 2010 08:34:22 -0400
Jesse Noller 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 question here is what o
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 thi
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 open
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 Quinlan wrote:
> >> Rename "executor" => "executer"
> >
> > -1 for consistency with Java.
>
> -10 for 'executer'. As far as I can find out, it is a misspelling of
> 'execut
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 J
On 24 May 2010 03:58, Cameron Simpson 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 debugging it.
On 24May2010 10:47, Stephen J. Turnbull wrote:
| Brian Quinlan writes:
| > If you are familiar with threads then writing a "good enough" solution
| > without futures probably won't take you very long. Also, unless you
| > are familiar with another futures implementation, you aren't likely t
Brian Quinlan writes:
> If you are familiar with threads then writing a "good enough" solution
> without futures probably won't take you very long. Also, unless you
> are familiar with another futures implementation, you aren't likely to
> know where to look.
That looks like an argument
Andrew Svetlov wrote:
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
I think this is an English vs. American thing. Double 'l'
looks right to me, but then I was brought up as a loyal
subject of the antipodean branch of the British Empire. :-)
--
Greg
1 - 100 of 143 matches
Mail list logo
