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
Hi,
issue991196 was closed being described as intentional. I've added
a comment in that issue which argues that this is a serious bug (also
aserted by a previous commenter - Armin Rigo), because it creates a
unique, undocumented, oddly behaving scope that doesn't apply closures
correctly. At
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, May 26, 2010 at 10:15 AM, Colin H hawk...@gmail.com wrote:
issue991196 was closed being described as intentional. I've added
a comment in that issue which argues that this is a serious bug (also
aserted by a previous commenter - Armin Rigo), because it creates a
unique,
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
Le mercredi 26 mai 2010 à 13:19 +0100, Paul Moore a écrit :
I'm not sure how a Sumo approach would work in practical terms, and
this thread isn't really the place to discuss, but there's a couple of
points I think are worth making:
* For a Sumo distribution to make sense, some relatively
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 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug, and if it is a bug, how it
could be resolved. What would the impact be of having
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 11:48, Mark Dickinson dicki...@gmail.com wrote:
On Wed, May 26, 2010 at 10:15 AM, Colin H hawk...@gmail.com wrote:
issue991196 was closed being described as intentional. I've added
a comment in that issue which argues that this is a serious bug (also
aserted by a
On 26/05/2010 13:51, Nick Coghlan wrote:
On 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug, and if it is a bug, how it
could be
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:08, Michael Foord wrote:
On 26/05/2010 13:51, Nick Coghlan wrote:
On 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug,
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
Thanks for the details on why the observed behaviour occurs - very
clear. My only query would be why this is considered correct? Why is
it running as a class namespace, when it is not a class? Is there any
reason why this is not considered a mistake? Slightly concerned that
this is being
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 Wed, May 26, 2010 at 5:46 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le mercredi 26 mai 2010 à 13:19 +0100, Paul Moore a écrit :
I'm not sure how a Sumo approach would work in practical terms, and
this thread isn't really the place to discuss, but there's a couple of
points I think 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
Mark Dickinson wrote (with interactice prompts removed)
code = \
y = 3
def f():
return y
. f()
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Traceback (most recent call last):
File stdin, line 1, in module
File string, line 4, in module
File string, line
The changes to the docs will definitely help in understanding why this
behaves as it does. I would like like to take one last stab though at
justifying why this behaviour isn't correct - will leave it alone if
these arguments don't stack up :) Appreciate the input and
discussion.
Terry Jan Reedy
On 26 May 2010 13:46, Antoine Pitrou solip...@pitrou.net wrote:
This is not what I'm suggesting at all. The stdlib wouldn't shrink
(well, we could dump outdated modules but that's a separate decision).
Ah, OK. In that case, I see the argument for a Sumo distribution as
weak for a different
Le mercredi 26 mai 2010 à 23:41 +0100, Paul Moore a écrit :
But a general
purpose Sumo distribution *on top of* the stdlib? I'm skeptical.
(Personally, my essential extras are pywin32, cx_Oracle and that's
about it - futures might make it if it doesn't get into the stdlib,
but that's about
On Wed, May 26, 2010 at 3:41 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 26 May 2010 13:46, Antoine Pitrou solip...@pitrou.net wrote:
This is not what I'm suggesting at all. The stdlib wouldn't shrink
(well, we could dump outdated modules but that's a separate decision).
Ah, OK. In that
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
Mark Dickinson wrote:
code = \
... y = 3
... def f():
... return y
... f()
...
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the first
On 27/05/2010 00:38, Greg Ewing wrote:
Mark Dickinson wrote:
code = \
... y = 3
... def f():
... return y
... f()
...
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for
Let me quickly jump in before someone actually deletes the feature.
Nick Coghlan and Thomas Wouters had it right; there is still a use
case. Don't kill it -- documenting it better is of course fine.
It *might* be possible to add a closure to the definition of f in the
case where globals !=
On 27/05/10 09:11, geremy condra wrote:
Specialised distributions are another matter - I can see a web stack
distribution comprising your TurboGears example (or should it be
Django, or...?). Enthought essentially do that for a Scientific
Python distribution. There could easily be others. But a
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 06:07, Colin H wrote:
In original Python, the snippet would have given an error whether you
thought of it as being in a class or function context, which is how
anyone who knew Python then would have expected. Consistency is not a bug.
When nested function namespaces were
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 Wed, May 26, 2010 at 4:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27/05/10 09:11, geremy condra wrote:
Specialised distributions are another matter - I can see a web stack
distribution comprising your TurboGears example (or should it be
Django, or...?). Enthought essentially do that
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
Mark Dickinson wrote:
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the first place. Are there any use cases for
it? Maybe the second scope argument to exec() should
be deprecated?
It is running as class namespace that
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27/05/10 06:07, Colin H wrote:
In original Python, the snippet would have given an error whether you
thought of it as being in a class or function context, which is how
anyone who knew Python then would have expected.
On Wed, May 26, 2010 at 5:37 PM, Colin H hawk...@gmail.com wrote:
Mark Dickinson wrote:
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the first place. Are there any use cases for
it? Maybe the second scope argument to
Hi Guido,
Thanks for the possible workaround - unfortunately 'stuff' will
contain a whole stack of things that are not in 'context', and were
not defined in 'user_code' - things that python embeds - a (very
small) selection -
{..., 'NameError': type 'exceptions.NameError', 'BytesWarning':
At 11:41 PM 5/26/2010 +0100, Paul Moore wrote:
I'm genuinely struggling to see how a Sumo distribution ever comes
into being under your proposal. There's no evidence that anyone wants
it (otherwise it would have been created by now!!)
Actually, sumo distributions *have* been created; it's just
On Wed, May 26, 2010 at 5:53 PM, Colin H hawk...@gmail.com wrote:
Thanks for the possible workaround - unfortunately 'stuff' will
contain a whole stack of things that are not in 'context', and were
not defined in 'user_code' - things that python embeds - a (very
small) selection -
{...,
Of course :) - I need to pay more attention. Your workaround should do
the trick. It would make sense if locals could be used for this
purpose, but the workaround doesn't add so much overhead in most
situations. Thanks for the help, much appreciated,
Colin
On Thu, May 27, 2010 at 2:05 AM, Guido
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
Because scientists, financial analysts, web designers, etc all have
different needs.
My point is just that a web designer probably doesn't care if he's
got numpy, nor does a mathematician care if he has cherrypy
onboard. They only care when the tools they need aren't there,
which is
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 11:33, Michael Foord wrote:
On 27/05/2010 00:38, Greg Ewing wrote:
Maybe the second scope argument to exec() should
be deprecated?
Sounds good to me, certainly ends the confusion over this undoubtedly
unintuitive behaviour. :-)
Although it's a fair point that it can be useful
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
On 27/05/10 12:37, Colin H wrote:
This is a major use
case for exec() - defining code from strings (e.g. enabling you to
store python code in the database), and using it at runtime. It seems
to me this must have been the point of locals in the first place.
I suspect that originally it just
On 27/05/10 12:38, Guido van Rossum wrote:
the compiler normally uses syntactic clues to decide
whether to generate code using closures, in particular, the presence
of nested functions.
Well, the compiler could be passed a flag indicating that
the code is being compiled for an exec statement.
Another approach to all this might be to generalise the
mechanism by which a lookup of the globals falls back
to a lookup of __builtins__.
If this were done recursively, then the stuff could
be attached to the globals dict, e.g.
stuff['__builtins__'] = __builtins__
g = dict(__builtins__ =
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
Hello,
sorry to interrupt your discussion but..
On Thu, May 27, 2010 at 04:09, Yaniv Aknin ya...@aknin.name wrote:
Because scientists, financial analysts, web designers, etc all have
different needs.
My point is just that a web designer probably doesn't care if he's
got numpy, nor does a
79 matches
Mail list logo
