On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan <br...@sweetapp.com> 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
