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
Hello,
sorry to interrupt your discussion but..
On Thu, May 27, 2010 at 04:09, Yaniv Aknin 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 mathem
>
> 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
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__ =
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.
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 fel
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 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 t
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
>
> > 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,
> whic
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
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 Wed, May 26, 2010 at 5:53 PM, Colin H 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 -
>
> {..., 'NameError': ,
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
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': , 'BytesWarning':
, 'dict': , 'input':
, 'oct': ,
On Wed, May 26, 2010 at 5:37 PM, Colin H 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 exec() shou
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlan 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. Consis
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 th
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 Wed, May 26, 2010 at 4:57 PM, Nick Coghlan 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 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 related
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 introduced
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)
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
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 != locals,
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 to
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 fi
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:41 PM, Paul Moore wrote:
> On 26 May 2010 13:46, Antoine Pitrou 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
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
On 26 May 2010 13:46, Antoine Pitrou 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 reason - for general
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
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 "", line 1, in
File "", line 4, in
File "", line 3, in f
NameError:
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 5:46 AM, Antoine Pitrou 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 worth mak
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
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 considered
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: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: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/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 resol
On Wed, May 26, 2010 at 11:48, Mark Dickinson wrote:
> On Wed, May 26, 2010 at 10:15 AM, Colin H 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 R
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 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 t
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 -
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 rel
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, May 26, 2010 at 10:15 AM, Colin H 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, undocumented, oddly behavi
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
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 t
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
81 matches
Mail list logo
