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
One worry with an official sumo distribution is that it could become
an excuse for *not* putting something in the stdlib.
Otherwise it's an interesting idea.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
On 27 May 2010 00:11, geremy condra debat...@gmail.com wrote:
I'm not clear, you seem to be arguing that there's a market for many
augmented python distributions but not one. Why not just have one
that includes the best from each domain?
Because that's bloat. You later argue that a web
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
OK, I had an idea here:
How about that the people affected by difficulties in getting software
approved got together to put together not a sumo-python, but a
python-extras package? That package could include all the popular
stuff, like SciPy, Numpy, twisted, distribute, buildout, virtualenv,
pip,
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
I needed to make a small modification to the workaround - I wasn't
able to delete from 'stuff', as the definitions in exec()'d code won't
run - they're relying on that being present at runtime. In practice
the overhead of doing this is quite noticeable if you run your code
like this a lot, and
On 5/27/2010 7:14 AM, Colin H wrote:
def define_stuff(user_code):
context = {...}
stuff = {}
stuff.update(context)
exec(user_code, stuff)
return_stuff = {}
return_stuff.update(stuff)
del return_stuff['__builtins__']
for key in context:
if key in return_stuff and
Yep fair call - was primarily modifying Guido's example to make the
point about not being able to delete from the globals returned from
exec - cheers,
Colin
On Thu, May 27, 2010 at 2:09 PM, Scott Dial
scott+python-...@scottdial.com wrote:
On 5/27/2010 7:14 AM, Colin H wrote:
def
Just to put a couple of alternatives on the table that don't break
existing code - not necessarily promoting them, or suggesting they
would be easy to do -
1. modify exec() to take an optional third argument - 'scope_type' -
if it is not supplied (but locals is), then it runs as class namespace
-
On 27/05/10 10:38, Guido van Rossum wrote:
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlanncogh...@gmail.com wrote:
Lexical scoping only works for code that is compiled as part of a single
operation - the separation between the compilation of the individual string
and the code defining that
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
Paul Moore writes:
On 27 May 2010 00:11, geremy condra debat...@gmail.com wrote:
I'm not clear, you seem to be arguing that there's a market for many
augmented python distributions but not one. Why not just have one
that includes the best from each domain?
Because that's bloat. You
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 27/05/10 13:13, Greg Ewing wrote:
The way that functions get access to names in enclosing
local scopes is by having them passed in as cells, but that
mechanism is only available for optimised local namespaces,
not ones implemented as dicts.
I believe exec already includes the tapdancing
Lennart Regebro writes:
One worry with an official sumo distribution is that it could become
an excuse for *not* putting something in the stdlib.
Otherwise it's an interesting idea.
On the contrary, that is the meat of why it's an interesting idea.
I really don't think the proponents of
On 27/05/2010 16:56, Stephen J. Turnbull wrote:
Paul Moore writes:
On 27 May 2010 00:11, geremy condradebat...@gmail.com wrote:
I'm not clear, you seem to be arguing that there's a market for many
augmented python distributions but not one. Why not just have one
that
Lennart Regebro writes:
If licensing is a problem I guess you'd need to have permission to
relicense them all to the Python license,
Licensing compatibility is only a problem for copyleft, but most
copyleft licenses have mere aggregation is not derivation clauses.
Corporate concern about
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
Michael Foord writes:
To my mind one of the most important benefits of a sumo style
distribution is not just that it easily provides a whole bunch of useful
modules - but that it *highlights* which modules are the community
blessed best of breed.
That has several problems.
(1) There
On 27 May 2010 16:56, Stephen J. Turnbull step...@xemacs.org wrote:
We'll just have to agree to disagree, then. Plenty of evidence has
been provided; it just doesn't happen to apply to you. Fine, but I
wish you'd make the to me part explicit, because I know that it does
apply to others,
On Thu, May 27, 2010 at 11:42 AM, Nick Coghlan ncogh...@gmail.com wrote:
However, attaining the (sensible) behaviour Colin is requesting when such
top level variable references exist would actually be somewhat tricky.
Considering Guido's suggestion to treat two argument exec like a function
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
This option sounds very promising - seems right to do it at the
compile stage - i.e. compile(code_str, name, closure) as you have
suggested. If there were any argument against, it would be that the
most obvious behaviour (function namespace) is the hardest to induce,
but the value in knowing
By hardest to induce I mean the default compile exec(code_str, {}, {})
would still be class namespace, but it's pretty insignificant.
On Fri, May 28, 2010 at 12:32 AM, Colin H hawk...@gmail.com wrote:
This option sounds very promising - seems right to do it at the
compile stage - i.e.
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
34 matches
Mail list logo
