Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote:

On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan   
wrote:

import futures

+1 on the idea, -1 on the name.  It's too similar to "from  
__future__ import ...".


Also, the PEP should probably link to the discussions on stdlib-sig?


I thought about that but this discussion is spread over many threads  
and many months.


Cheers,
Brian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 6 Mar 2010, at 07:38, Brett Cannon wrote:

The PEP says that futures.wait() should only use keyword arguments  
past its first positional argument, but the PEP has the function  
signature as ``wait(fs, timeout=None, return_when=ALL_COMPLETED)``.   
Should it be ``wait(fs, *, timeout=None, return_when=ALL_COMPLETED)``?


Hi Brett,

That recommendation was designed to make it easy to change the API  
without breaking code.


I'd don't think that recommendation makes sense anymore any I'll  
update the PEP.


Cheers,
Brian

On Thu, Mar 4, 2010 at 22:03, Brian Quinlan   
wrote:

Hi all,

I recently submitted a daft PEP for a package designed to make it  
easier to execute Python functions asynchronously using threads and  
processes. It lets the user focus on their computational problem  
without having to build explicit thread/process pools and work queues.


The package has been discussed on stdlib-sig but now I'd like this  
group's feedback.


The PEP lives here:
http://python.org/dev/peps/pep-3148/

Here are two examples to whet your appetites:

"""Determine if several numbers are prime."""
import futures
import math

PRIMES = [
   112272535095293,
   112582705942171,
   112272535095293,
   115280095190773,
   115797848077099,
   1099726899285419]

def is_prime(n):
   if n % 2 == 0:
   return False

   sqrt_n = int(math.floor(math.sqrt(n)))
   for i in range(3, sqrt_n + 1, 2):
   if n % i == 0:
   return False
   return True

# Uses as many CPUs as your machine has.
with futures.ProcessPoolExecutor() as executor:
   for number, is_prime in zip(PRIMES, executor.map(is_prime,  
PRIMES)):

   print('%d is prime: %s' % (number, is_prime))


"""Print out the size of the home pages of various new sites (and  
Fox News)."""

import futures
import urllib.request

URLS = ['http://www.foxnews.com/',
   'http://www.cnn.com/',
   'http://europe.wsj.com/',
   'http://www.bbc.co.uk/',
   'http://some-made-up-domain.com/']

def load_url(url, timeout):
   return urllib.request.urlopen(url, timeout=timeout).read()

with futures.ThreadPoolExecutor(max_workers=5) as executor:
   # Create a future for each URL load.
   future_to_url = dict((executor.submit(load_url, url, 60), url)
for url in URLS)

   # Iterate over the futures in the order that they complete.
   for future in futures.as_completed(future_to_url):
   url = future_to_url[future]
   if future.exception() is not None:
   print('%r generated an exception: %s' % (url,
 
future.exception()))

   else:
   print('%r page is %d bytes' % (url, len(future.result(

Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/brett%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 6 Mar 2010, at 08:42, Jesse Noller wrote:

If people agree with this; do you feel the proposal of said namespace
should be a separate PEP, or piggy back on this? I don't want to piggy
back on Brian's hard work.


It doesn't really matter to me.

We can either update this PEP to propose the concurrent.futures name  
or you can draft a more complete PEP that describes what other  
functionality should live in the concurrent package.


Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:


Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan  a écrit :


The PEP lives here:
http://python.org/dev/peps/pep-3148/


Ok, here is my take on it:


cancel()

Attempt to cancel the call. If the call is currently being executed
then it cannot be cancelled and the method will return False,
otherwise the call will be cancelled and the method will return
True.


I think it shouldn't return anything, and raise an exception if
cancelling failed. It is really an error condition, and ignoring the
result doesn't seem right.


In my experience with futures, canceling them is a best-effort  
optimization that people use when another future fails. For example:


futures = [executor.submit(CopyDirectory, src, dest) for dest in ...]
finished, unfinished = wait(futures, return_when=FIRST_EXCEPTION)
# If there are unfinished futures then there must have been a failure
for f in unfinished:
  # No reason to waste bandwidth copying files if the operation has  
already failed.

  f.cancel()
for f in finished():
  if f.exception():
raise f.exception()


Future.running()

Return True if the call is currently being executed and cannot be
cancelled.

Future.done()

Return True if the call was successfully cancelled or finished
running.


These don't really make sense since the future is executing
concurrently. By the time the result is returned, it can already be
wrong. I advocate removing those two methods.


There methods are useful for logging - by displaying the count of  
pending, running and completed futures you can estimate the progress  
of the system.



The following Future methods are meant for use in unit tests and
Executor implementations.


Their names should then be preceded by an underscore '_'. We don't  
want

people to think they are public APIs and start relying on them.


Actually, as discussed on the stdlib-sig, these methods are designed  
to make it possible for users to implement their own Executors so  
we'll have keep the interface stable.



wait(fs, timeout=None, return_when=ALL_COMPLETED)
[...]

This method should always be called using keyword arguments


I don't think this is right. Keyword arguments are nice, but mandating
them too often is IMO a nuisance (after all, it makes things longer to
type and requires you to remember the exact parameter names).
Especially when the method only takes at most 3 arguments.

IMO, keyword-only arguments are mostly useful when there are a lot of
positional arguments before, and you want to help the user use the
right calling signature.


I agree, I'll change this.

Cheers,
Brian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 6 Mar 2010, at 17:50, Phillip J. Eby wrote:


At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote:
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby > wrote:
> I'm somewhat concerned that, as described, the proposed API ...  
[creates] yet another alternative (and

> mutually incompatible) event loop system in the stdlib ...

Futures are a blocking construct; they don't involve an event loop.


And where they block is in a loop, waiting for events (completed  
promises) coming back from other threads or processes.


The Motivation section of the PEP also stresses avoiding reinvention  
of such loops, and points to the complication of using more than one  
at a time as a justification for the mechanism.  It seems relevant  
to at least address why wrapping multiprocessing and multithreading  
is appropriate, but *not* dealing with any other form of sync/async  
boundary, *or* composition of futures.


On which subject, I might add, the PEP is silent on whether  
executors are reentrant to the called code.  That is, can I call a  
piece of code that uses futures, using the futures API?  How will  
the called code know what executor to use?  Must I pass it one  
explicitly?  Will that work across threads and processes, without  
explicit support from the API?


Executors are reentrant but deadlock is possible. There are two  
deadlock examples in the PEP.




IOW, as far as I can tell from the PEP, it doesn't look like you can  
compose futures without *global* knowledge of the application...   
and in and of itself, this seems to negate the PEP's own motivation  
to prevent duplication of parallel execution handling!


That is, if I use code from module A and module B that both want to  
invoke tasks asynchronously, and I want to invoke A and B  
asynchronously, what happens?  Based on the design of the API, it  
appears there is nothing you can do except refactor A and B to take  
an executor in a parameter, instead of creating their own.


A and B could both use their own executor instances. You would need to  
refactor A and B if you wanted to manage thread and process counts  
globally.


It seems therefore to me that either the proposal does not define  
its scope/motivation very well, or it is not well-equipped to  
address the problem it's setting out to solve.  If it's meant to be  
something less ambitious -- more like a recipe or example -- it  
should properly motivate that scope.  If it's intended to be a  
robust tool for composing different pieces of code, OTOH, it should  
absolutely address the issue of writing composable code...  since,  
that seems to be what it says the purpose of the API is.  (I.e.,  
composing code to use a common waiting loop.)


My original motivation when designing this module was having to deal  
with a lot of code that looks like this:


def get_some_user_info(user):
  x = make_ldap_call1(user)
  y = make_ldap_call2(user)
  z = [make_db_call(user, i) for i in something]

  # Do some processing with x, y, z and return a result

Doing these operations serially is too slow. So how do I parallelize  
them? Using the threading module is the obvious choice but having to  
create my own work/result queue every time I encounter this pattern is  
annoying. The futures module lets you write this as:


def get_some_user_info(user):
  with ThreadPoolExecutor(max_threads=10) as executor:
x_future = executor.submit(make_ldap_call1, user)
y_future = executor.submit(make_ldap_call2, user)
z_futures = [executor.submit(make_db_call, user, i) for i in  
something]
   finished, _ = wait([x_future, y_future] + z_futures,  
return_when=FIRST_EXCEPTION)

 for f in finished:
   if f.exception():
 raise f.exception()
 x = x_future.result()
 y = y_future.result()
 z = [f.result() for f in z_futures]

  # Do some processing with x, y, z and return a result

And, existing Python async APIs (such as Twisted's Deferreds)  
actually *address* this issue of composition; the PEP does not.   
Hence my comments about not looking at existing implementations for  
API and implementation guidance.  (With respect to what the API  
needs, and how it needs to do it, not necessarily directly copying  
actual APIs or implementations.  Certainly some of the Deferred API  
naming has a rather, um, "twisted" vocabulary.)


Using twisted (or any other asynchronous I/O framework) forces you to  
rewrite your I/O code. Futures do not.


Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

Brian Quinlan wrote:
> 
> On 6 Mar 2010, at 08:42, Jesse Noller wrote:
>> If people agree with this; do you feel the proposal of said namespace
>> should be a separate PEP, or piggy back on this? I don't want to piggy
>> back on Brian's hard work.
> 
> It doesn't really matter to me.
> 
> We can either update this PEP to propose the concurrent.futures name or
> you can draft a more complete PEP that describes what other
> functionality should live in the concurrent package.

I think a "concurrent.futures" name works - it gives the scoping desired
by the folks with an finance background and gives us a bucket for future
thread/process agnostic concurrency tools (such as a pools and message
queues).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Stephen J. Turnbull]

Jeffrey Yasskin writes:

 > It seems like a good idea to follow the choice other languages have
 > used for the name (if they tend to agree)

For the record, I've conceded that point.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

Brian Quinlan wrote:
>> IOW, as far as I can tell from the PEP, it doesn't look like you can
>> compose futures without *global* knowledge of the application...  and
>> in and of itself, this seems to negate the PEP's own motivation to
>> prevent duplication of parallel execution handling!
>>
>> That is, if I use code from module A and module B that both want to
>> invoke tasks asynchronously, and I want to invoke A and B
>> asynchronously, what happens?  Based on the design of the API, it
>> appears there is nothing you can do except refactor A and B to take an
>> executor in a parameter, instead of creating their own.
> 
> A and B could both use their own executor instances. You would need to
> refactor A and B if you wanted to manage thread and process counts
> globally.

You may want to consider providing global thread and process executors
in the futures module itself. Code which just wants to say "do this in
the background" without having to manage the lifecycle of its own
executor instance is then free to do so. I've had a lot of experience
with a framework that provides this and it is *very* convenient (it's
also a good way to avoid deadlocks due to synchronous notification APIs).


On PJE's broader point, async event loops with non-blocking I/O and
messages passed back to the event loop to indicate completion of
operations and relying on threads and processes to farm out tasks (which
you will later block on in order to retrieve the results) are completely
different programming models. This PEP doesn't change that - it just
makes certain aspects of the latter approach easier to handle.

Trying to design an API that can cope with either model strikes me as a
fool's errand. They differ at such a fundamental level that I don't see
how a hybrid API could be particularly optimal for either approach.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] argparse ugliness

[Nick Coghlan]

Neal Becker wrote:
> I generally enjoy argparse, but one thing I find rather
> ugly and unpythonic.
> 
> parser.add_argument ('--plot', action='store_true')
> 
> Specifying the argument 'action' as a string is IMO ugly.

It isn't ideal, but having to grab constants from the module isn't ideal
either.

Using a string here allows argparse (and optparse before it) to spit out
an explicit "unknown action" message. Using named constants a typo would
just get you a generic NameError instead. With variable names only being
checked at runtime, you wouldn't get the static name checking that is
the primary benefit of using named constants in less dynamic languages.

So, agreed that using strings isn't pretty, but there aren't any great
alternatives available.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Daniel Stutzbach]

On Sat, Mar 6, 2010 at 6:43 AM, Nick Coghlan  wrote:

> You may want to consider providing global thread and process executors
> in the futures module itself. Code which just wants to say "do this in
> the background" without having to manage the lifecycle of its own
> executor instance is then free to do so.


+1
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Phillip J. Eby]

At 05:32 AM 3/6/2010, Brian Quinlan wrote:

Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.


Twisted's "Deferred" API has nothing to do with I/O. 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Modifying Grammar/grammar and other foul acts

[Gregg Lind]

Python-devs,

I'm writing to you for some help in understanding the Python grammar.  As an
excuse to deep dive into Python's tokenizer / grammar, I decided (as a
hideous, hideous joke) to want to allow braces where colons are allowed (as
flow control).

Starting from PEP 306 (and branch r311), I hacked on Grammar/Grammer

As a first example:

funcdef: ('def' NAME parameters ['->' test] ':' suite |
  'def' NAME parameters ['->' test] '{' suite '}' )

I reran Parser/pgen and the dfa changes, but python (3.1) when recompiled,
throws errors on things like:

def a() { None }

Strangely enough:

lambdef: ( 'lambda' [varargslist] ':' test  |
   'lambda' [varargslist] '{' test '}' )

works fine!  I this simplely some difference between "test" and "suite".

I have tried tackling this with gdb, looking at err_input clearly isn't
enough.

(gdb) break err_input
(gdb) break PyParser_ASTFromString
import sys
b = compile("def a() {pass}","sys.stdout","single")
# yet a simple grammar fix is enough for this!
c = compile("lambda x {None}","sys.stdout","single")

I'm in over my head!

Any insights / help would be appreciated.  Full-on flaming is also
appropriate, but would be less appreciated.

Specific questions

1.)  I assume the Grammar/grammar is read top to bottom.  Confirm?
2.)  More help figuring out how to debug what python *thinks* it's seeing
when it see "def a() {pass}".  It's not getting to the ast construction
stage, as near as I can tell.  What additional breakpoints can I set to see
where it's failing.

Gregg L.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modifying Grammar/grammar and other foul acts

[Martin v. Löwis]

> 1.)  I assume the Grammar/grammar is read top to bottom.  Confirm?

Confirm - but this is not surprising: *any* source file is typically
read from top to bottom. Randoma access reading is typically done for
binary files, only.

So you must be asking something else, but I can't guess what that might be.

> 2.)  More help figuring out how to debug what python *thinks* it's
> seeing when it see "def a() {pass}".  It's not getting to the ast
> construction stage, as near as I can tell.  What additional breakpoints
> can I set to see where it's failing. 

Enable the D() debugging in parser.c (configure with --with-pydebug,
and set PYTHONDEBUG).

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] argparse ugliness

[Xavier Morel]

I don't believe argparse's action specification scheme is bad either, but

On 6 Mar 2010, at 13:50 , Nick Coghlan wrote:
> 
> you wouldn't get the static name checking that is
> the primary benefit of using named constants in less dynamic languages.

There are quite a few tools which do handle static checking of that kind
of stuff, so while Python itself doesn't provide it (as a builtin) it's
not like you can't get it some other way.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modifying Grammar/grammar and other foul acts

[Gregg Lind]

Sorry, re: question one, forgive the ill-formed question.  I meant more, are
the parser rules applied "first matching".   Essentially trying to confirm
that the parser is "top down" or "bottom up" or whether or not it even
matters.

Thanks for the tip -- it seems to be exactly what I want.  To make it
explicit, this seems to be fuller (unix) recipe for how to make this style
of debugging happen.

$ ./configure --with-pydebug
$ make
$ set PYTHONDEBUG=1
$ ./python -d   # then this shows the parsing info


On Sat, Mar 6, 2010 at 10:56 AM, "Martin v. Löwis" wrote:

> > 1.)  I assume the Grammar/grammar is read top to bottom.  Confirm?
>
> Confirm - but this is not surprising: *any* source file is typically
> read from top to bottom. Randoma access reading is typically done for
> binary files, only.
>
> So you must be asking something else, but I can't guess what that might be.
>
> > 2.)  More help figuring out how to debug what python *thinks* it's
> > seeing when it see "def a() {pass}".  It's not getting to the ast
> > construction stage, as near as I can tell.  What additional breakpoints
> > can I set to see where it's failing.
>
> Enable the D() debugging in parser.c (configure with --with-pydebug,
> and set PYTHONDEBUG).
>
> Regards,
> Martin
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Silencing DeprecationWarning by default in Python 2.7 is silencing division warnings

[Brett Cannon]

I see two possible fixes for this. One is to not silence DeprecationWarning
if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new
subclass of DeprecationWarning called IntegerDivisionWarning and have that
added to the warnings filter so that if it is triggered it is handled
separately from what DeprecationWarning triggers.

The former means that you might get more than you bargained for in terms of
warnings as you are suddenly switching on all DeprecationWarnings on top of
division warnings. The latter means that you now have to explicit care about
IntegerDivisionWarning on top of DeprecationWarning (to minimize this I
could have IntegerDivisionWarning added to the warnings filter only in the
case of when Py_DivisionWarningFlag is set instead of blindly adding it).

Thoughts?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Silencing DeprecationWarning by default in Python 2.7 is silencing division warnings

[Benjamin Peterson]

2010/3/6 Brett Cannon :
> I see two possible fixes for this. One is to not silence DeprecationWarning
> if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new
> subclass of DeprecationWarning called IntegerDivisionWarning and have that
> added to the warnings filter so that if it is triggered it is handled
> separately from what DeprecationWarning triggers.
> The former means that you might get more than you bargained for in terms of
> warnings as you are suddenly switching on all DeprecationWarnings on top of
> division warnings. The latter means that you now have to explicit care about
> IntegerDivisionWarning on top of DeprecationWarning (to minimize this I
> could have IntegerDivisionWarning added to the warnings filter only in the
> case of when Py_DivisionWarningFlag is set instead of blindly adding it).
> Thoughts?

How about just setting the warnings filter based on the integer
division warning message? Might be a little brittle, but I don't much
third party code is warning about classic division.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Dj Gilcrease]

I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/

When I was running in debug mode I found that as soon as

p = multiprocessing.Process(
target=_process_worker,
args=(self._call_queue,
  self._result_queue,
  self._shutdown_process_event))

was called (yes even before p.start() was called) the processes just
started launching all by themselves.

I am also wondering why you are launching the process directly instead
of using a Pool since you are limiting the number of processes always
wouldnt it be better to launch the worker processes up front then just
add worker items to the queue?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Dj Gilcrease]

I am also getting an odd error on odd error on exit

Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modifying Grammar/grammar and other foul acts

[Guido van Rossum]

On Sat, Mar 6, 2010 at 10:26 AM, Gregg Lind  wrote:
> Sorry, re: question one, forgive the ill-formed question.  I meant more, are
> the parser rules applied "first matching".   Essentially trying to confirm
> that the parser is "top down" or "bottom up" or whether or not it even
> matters.

That's not how it works at all. I can't explain it in a few words --
but any text on LL(1) parsing should clarify this. The parser uses no
backtracking and a 1-token lookahead. The only unusual thing is that
individual rules use a regex-like notation, but that is all converted
to a DFA. If one token is not enough to know which path to take
through the DFA (this may invoke another rule -- but you always know
which one) you're hosed.

I suspect you've introduced ambiguities, though I don't immediately
see where (they could be in the combination of different rules).

Another possibility is that you may be running into problems where the
parser expects a newline at the end of a suite.

(FWIW since you're not proposing a language change, this is
technically off-topic for python-dev. :-)

--Guido

> Thanks for the tip -- it seems to be exactly what I want.  To make it
> explicit, this seems to be fuller (unix) recipe for how to make this style
> of debugging happen.
>
>     $ ./configure --with-pydebug
>     $ make
>     $ set PYTHONDEBUG=1
>     $ ./python -d   # then this shows the parsing info
>
>
> On Sat, Mar 6, 2010 at 10:56 AM, "Martin v. Löwis" 
> wrote:
>>
>> > 1.)  I assume the Grammar/grammar is read top to bottom.  Confirm?
>>
>> Confirm - but this is not surprising: *any* source file is typically
>> read from top to bottom. Randoma access reading is typically done for
>> binary files, only.
>>
>> So you must be asking something else, but I can't guess what that might
>> be.
>>
>> > 2.)  More help figuring out how to debug what python *thinks* it's
>> > seeing when it see "def a() {pass}".  It's not getting to the ast
>> > construction stage, as near as I can tell.  What additional breakpoints
>> > can I set to see where it's failing.
>>
>> Enable the D() debugging in parser.c (configure with --with-pydebug,
>> and set PYTHONDEBUG).
>>
>> Regards,
>> Martin
>>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Jesse Noller]

On Mar 6, 2010, at 4:20 PM, Dj Gilcrease  wrote:


I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/

When I was running in debug mode I found that as soon as

   p = multiprocessing.Process(
   target=_process_worker,
   args=(self._call_queue,
 self._result_queue,
 self._shutdown_process_event))

was called (yes even before p.start() was called) the processes just
started launching all by themselves.



Did you run the provided example code on windows by chance? If so,  
look at the multiprocessing docs, there are restrictions on windows  
(see the __main__ note) - not following the guidelines can result in  
lots of processes spawning.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.1.2 release candidate

[Benjamin Peterson]

On behalf of the Python development team, I'm pleased to announce a release
candidate for the second bugfix release of the Python 3.1 series, Python 3.1.2.

This bug fix release fixes numerous issues found in 3.1.1.  This release
candidate has been released to solicit testing and feedback over an possible
regressions from 3.1.1.  Please consider testing it with your library or
application and reporting an bugs you encounter.  This will help make the final
3.1.2 release, planned in 2 weeks time, all the more stable.

The Python 3.1 version series focuses on the stabilization and optimization of
the features and changes that Python 3.0 introduced.  For example, the new I/O
system has been rewritten in C for speed.  File system APIs that use unicode
strings now handle paths with undecodable bytes in them. Other features include
an ordered dictionary implementation, a condensed syntax for nested with
statements, and support for ttk Tile in Tkinter.  For a more extensive list of
changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in
the Python distribution.

To download Python 3.1.2rc1 visit:

 http://www.python.org/download/releases/3.1.2/

A list of changes in 3.1.2rc1 can be found here:

 http://svn.python.org/projects/python/tags/r312rc1/Misc/NEWS

The 3.1 documentation can be found at:

 http://docs.python.org/3.1

Bugs can always be reported to:

 http://bugs.python.org


Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.1.2's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 2.7 alpha 4

[Benjamin Peterson]

On behalf of the Python development team, I'm overjoyed to announce the fourth
alpha release of Python 2.7.

Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version
in the 2.x series.  Though more major releases have not been absolutely ruled
out, it's likely that the 2.7 release will an extended period of maintenance for
the 2.x series.

2.7 includes many features that were first released in Python 3.1.  The faster
io module, the new nested with statement syntax, improved float repr, set
literals, dictionary views, and the memoryview object have been backported from
3.1. Other features include an ordered dictionary implementation, unittests
improvements, a new sysconfig module, and support for ttk Tile in Tkinter.  For
a more extensive list of changes in 2.7, see
http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python
distribution.

To download Python 2.7 visit:

 http://www.python.org/download/releases/2.7/

Please note that this is a development release, intended as a preview of new
features for the community, and is thus not suitable for production use.

The 2.7 documentation can be found at:

 http://docs.python.org/2.7

Please consider trying Python 2.7 with your code and reporting any bugs you may
notice to:

 http://bugs.python.org


Enjoy!

--
Benjamin Peterson
2.7 Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Ben Finney]

"Stephen J. Turnbull"  writes:

> I have to admit Jean-Paul's explanation a pretty convincing reason for
> adopting "future" rather than "promise". But I'm with Skip, I would
> prefer that the module be named "future" rather than "futures".

Has anyone in this very long thread raised the issue that Python
*already* uses this term for the name of a module with a totally
unrelated purpose; the ‘__future__’ pseudo-module?

That alone seems a pretty strong reason to avoid the word “future”
(singular or plural) for some other module name.

-- 
 \ “Creativity can be a social contribution, but only in so far as |
  `\society is free to use the results.” —Richard Stallman |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Jesse Noller]

On Mar 6, 2010, at 5:47 PM, Ben Finney   
wrote:



"Stephen J. Turnbull"  writes:

I have to admit Jean-Paul's explanation a pretty convincing reason  
for

adopting "future" rather than "promise". But I'm with Skip, I would
prefer that the module be named "future" rather than "futures".


Has anyone in this very long thread raised the issue that Python
*already* uses this term for the name of a module with a totally
unrelated purpose; the ‘__future__’ pseudo-module?

That alone seems a pretty strong reason to avoid the word “future”
(singular or plural) for some other module name.



Yes, they have, and putting it in a sub namespace has also come up. In  
the thread.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Greg Ewing]

Jeffrey Yasskin wrote:


The caller can't avoid the error here by querying the future, because
of the problem you point out below, so I'm inclined to think that "the
future was already started" should be a return value rather than an
exception (although that may be my C++ background showing through).


I think it's your C++ background showing. In Python philosophy,
there's no particlular connection between whether something can
be tested for and whether it should raise an exception.

The thing to consider, I think, is whether it makes sense in
a large proportion of use cases to ignore the fact that the
cancel failed and carry on regardless. If not, then raising an
exception makes it much harder to accidentally ignore the
situation.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] argparse ugliness

[Greg Ewing]

Antoine Pitrou wrote:


I would argue that a string is actually more Pythonic than
integers or anonymous objects repurposed as magic constants.
(I'm looking at things such as SEEK_SET and friends)


Strings are certainly preferable to ints, one reason being that
they display as something meaningful in debugging output.

But it also doesn't hurt to export named constants for them,
in the interests of catching typos.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Greg Ewing]

Phillip J. Eby wrote:
while at the same time creating yet another alternative (and 
mutually incompatible) event loop system in the stdlib, beyond the ones 
that are already in asyncore, tkinter, and the various SocketServer 
subclasses.


Aaargh... that's the *last* thing we need!

I've been thinking for a while that it would be a big help
if there were one, standardised module in the stdlib for
handling async events, and all the other gui toolkits
etc. were made to use it.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Michael Foord]

On 06/03/2010 23:37, Greg Ewing wrote:

Phillip J. Eby wrote:
while at the same time creating yet another alternative (and mutually 
incompatible) event loop system in the stdlib, beyond the ones that 
are already in asyncore, tkinter, and the various SocketServer 
subclasses.


Aaargh... that's the *last* thing we need!

I've been thinking for a while that it would be a big help
if there were one, standardised module in the stdlib for
handling async events, and all the other gui toolkits
etc. were made to use it.


Wouldn't it have to be the Tcl event loop then?

Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Greg Ewing]

Brian Quinlan wrote:

That recommendation was designed to make it easy to change the API 
without breaking code.


I'd don't think that recommendation makes sense anymore any I'll update 
the PEP.


I don't think there's anything wrong with stating that the
order of the arguments is not a guaranteed part of the API.
There isn't necessarily any need to enforce that, though.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Daniel Stutzbach]

On Sat, Mar 6, 2010 at 5:38 PM, Michael Foord wrote:

> On 06/03/2010 23:37, Greg Ewing wrote:
>
>> I've been thinking for a while that it would be a big help
>> if there were one, standardised module in the stdlib for
>> handling async events, and all the other gui toolkits
>> etc. were made to use it.
>>
>>  Wouldn't it have to be the Tcl event loop then?
>

I image he means a standardized Abstract Base Class, which each GUI toolkit
would subclass.  That's more or less how Twisted's "reactors" work.  That
way non-GUI async code can just use the ABC and not worry about what event
loop is running underneath (be it TCL, GTK, or just poll()).
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modifying Grammar/grammar and other foul acts

[Greg Ewing]

Gregg Lind wrote:
Sorry, re: question one, forgive the ill-formed question.  I meant more, 
are the parser rules applied "first matching".   Essentially trying to 
confirm that the parser is "top down" or "bottom up" or whether or not 
it even matters.


I think pgen would complain if you had two rules that could
both match at the same time, so the question doesn't apply.

BTW, be careful with terminology here -- the terms "top down"
and "bottom up" have a different meaning in parsing theory
(they refer to the way the parse tree is built, not the order
of matching in a list of rules).

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Greg Ewing]

Michael Foord wrote:


Wouldn't it have to be the Tcl event loop then?


No, tcl/tk would have to be threatened with the comfy chair
until it allowed itself to be spliced into the official
event loop somehow.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[skip]

Ben> Has anyone in this very long thread raised the issue that Python
Ben> *already* uses this term for the name of a module with a totally
Ben> unrelated purpose; the ‘__future__’ pseudo-module?

Yes, it's already come up.  While not quite the same it does remind me of
the __builtin__/__builtins__ confusion.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Dj Gilcrease]

On Sat, Mar 6, 2010 at 2:58 PM, Jesse Noller  wrote:
> Did you run the provided example code on windows by chance? If so, look at
> the multiprocessing docs, there are restrictions on windows (see the
> __main__ note) - not following the guidelines can result in lots of
> processes spawning.


Yes, on win7. I might recommend then that the examples in the PEP be
restructured to work correctly on windows by including the

if __name__ == '__main__':
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Brian Quinlan]

On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:


At 05:32 AM 3/6/2010, Brian Quinlan wrote:

Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.


Twisted's "Deferred" API has nothing to do with I/O.


I see, you just mean the API and not the underlying model.

We discussed the Deferred API on the stdlib-sig and I don't think that  
anyone expressed a preference for it over the one described in the PEP.


Do you have any concrete criticism?

Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[exarkun]

On 02:10 am, br...@sweetapp.com wrote:

On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:

At 05:32 AM 3/6/2010, Brian Quinlan wrote:

Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.


Twisted's "Deferred" API has nothing to do with I/O.


I see, you just mean the API and not the underlying model.

We discussed the Deferred API on the stdlib-sig and I don't think that 
anyone expressed a preference for it over the one described in the PEP.


Do you have any concrete criticism?


From reading some of the stdlib-sig archives, it sounds like there is 
general agreement that Deferreds and Futures can be used to complement 
each other, and that getting code that is primarily Deferred-based to 
integrate with Future-based code or vice versa should eventually be 
possible.


Do I have the right sense of people's feelings?

And relatedly, once Futures are accepted and implemented, are people 
going to use them as an argument to exclude Deferreds from the stdlib 
(or be swayed by other people making such arguments)?  Hopefully not, 
given what I read on stdlib-sig, but it doesn't hurt to check...


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Jesse Noller]

On Sat, Mar 6, 2010 at 9:34 PM,   wrote:
> On 02:10 am, br...@sweetapp.com wrote:
>>
>> On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
>>>
>>> At 05:32 AM 3/6/2010, Brian Quinlan wrote:

 Using twisted (or any other asynchronous I/O framework) forces you to
 rewrite your I/O code. Futures do not.
>>>
>>> Twisted's "Deferred" API has nothing to do with I/O.
>>
>> I see, you just mean the API and not the underlying model.
>>
>> We discussed the Deferred API on the stdlib-sig and I don't think that
>> anyone expressed a preference for it over the one described in the PEP.
>>
>> Do you have any concrete criticism?
>
> From reading some of the stdlib-sig archives, it sounds like there is
> general agreement that Deferreds and Futures can be used to complement each
> other, and that getting code that is primarily Deferred-based to integrate
> with Future-based code or vice versa should eventually be possible.
>
> Do I have the right sense of people's feelings?
>
> And relatedly, once Futures are accepted and implemented, are people going
> to use them as an argument to exclude Deferreds from the stdlib (or be
> swayed by other people making such arguments)?  Hopefully not, given what I
> read on stdlib-sig, but it doesn't hurt to check...
>
> Jean-Paul

Generally speaking; I don't see futures as an exclusion to Deferreds,
or other asynchronous doodads. I just see it as a useful construct on
top of threads and processes primarily. So in my mind, no.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Dj Gilcrease]

After playing with the API for a while & running into many issues with
the examples & tests crashing windows I decided to modify the API a
little and fix up the examples so they dont crash windows based
computers.

http://code.google.com/p/pythonfutures/issues/detail?id=1

API Change that changes the current Executor to ExecutorBase and
adds a new Executor class that is used like

futures.Executor() # creates an executor that uses threading and a
max_workers = to the number of cpus

futures.Executor(use='process') # Creates an executor that uses
multiprocessing and a max_workers = to the number of cpus

futures.Executor(max_workers=5) # threading again, just specifying the
number of workers

futures.Executor(use='process', max_workers=5) # back to multiprocessing,
but with the max_workers specified
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[P.J. Eby]

At 01:10 PM 3/7/2010 +1100, Brian Quinlan wrote:

On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:


At 05:32 AM 3/6/2010, Brian Quinlan wrote:

Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.


Twisted's "Deferred" API has nothing to do with I/O.


I see, you just mean the API and not the underlying model.

We discussed the Deferred API on the stdlib-sig and I don't think that
anyone expressed a preference for it over the one described in the PEP.

Do you have any concrete criticism?


Of the PEP, yes, absolutely, and I've already stated much of it.  My 
quibbles are with the PEP *itself*, not so much the API or implementation.


I think that said API and implementation is fine, but FAR too 
narrowly scoped to claim to be "futures" or "execute computations 
asynchronously", as the PEP calls it.  It's really just a nice task 
queuing system.


Now, if the PEP were *scoped* as such, i.e., "hey, let's just have a 
nice multithread/multiprocess task queuing implementation in the 
stdlib", I would be +1.  It's a handy utility to have.


But I think that the scope given by the PEP appears overly ambitious 
compared to what is actually being delivered; this seems less of a 
"futures API" and more like a couple of utility functions for waiting 
on threads and processes.


To rise to the level of an API, it seems to me that it would need to 
address interop with coroutines and async frameworks, where the idea 
of "futures" seems much more relevant than simple 
synchronous-but-parallel scripts.  (It should also have better tools 
for working with futures asynchronously, because, hey, it says right 
there in the title, "execute computations asynchronously".)


Anyway, I'd like to see the answers to (at *least*) the following 
issues fleshed out in the PEP, if you want it to really be a "futures 
API", vs. "nice task queue in the stdlib":


* Compare/contrast alternatives now available
* Address the issue of competing event loops and sharing/passing 
executors among code
* Either offer a way for executed code to re-enter its own executor 
(e.g. via an optional parameter), or explain why this was considered 
and rejected
* Address interoperability with coroutines and async frameworks, or 
clearly explain why such is out of scope


(Personally, I think it would be better to just drop the ambitious 
title and scope, and go for the "nice task queue" scope.  I imagine, 
too, that in that case Jean-Paul wouldn't need to worry about it 
being raised as a future objection to Deferreds or some such getting 
into the stdlib.)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

Greg Ewing wrote:
> The thing to consider, I think, is whether it makes sense in
> a large proportion of use cases to ignore the fact that the
> cancel failed and carry on regardless. If not, then raising an
> exception makes it much harder to accidentally ignore the
> situation.

Cancelling operations is generally a best effort activity - having to
wrap it an exception handler would be annoying.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

P.J. Eby wrote:
> (Personally, I think it would be better to just drop the ambitious title
> and scope, and go for the "nice task queue" scope.  I imagine, too, that
> in that case Jean-Paul wouldn't need to worry about it being raised as a
> future objection to Deferreds or some such getting into the stdlib.)

This may be a terminology thing - to me futures *are* just a nice way to
handle farming tasks out to worker threads or processes. You seem to see
them as something more comprehensive than that.

I agree the PEP should just target what the current implementation
provides and put whatever scope limitations are needed in the preamble
text to make that clear.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com