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
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 wrote:
> This option sounds very promising - seems right to do it at the
> compile stage - i.e. compile(code_str, name, "
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 you
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 Thu, May 27, 2010 at 11:42 AM, Nick Coghlan 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
> rather than a cla
On 27 May 2010 16:56, Stephen J. Turnbull 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, many of them, fr
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)
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
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 27/05/2010 16:56, Stephen J. Turnbull wrote:
Paul Moore writes:
> On 27 May 2010 00:11, geremy condra 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
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
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 o
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 need
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
Paul Moore writes:
> On 27 May 2010 00:11, geremy condra 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 a
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 27/05/10 10:38, Guido van Rossum wrote:
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlan 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 string means that the s
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
-
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
wrote:
> On 5/27/2010 7:14 AM, Colin H wrote:
>> def define_stuff(user_code):
>> context = {.
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 retu
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 buil
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
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 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 27 May 2010 00:11, geremy condra 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 designer wouldn't
car
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
_
36 matches
Mail list logo
