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. > 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. > 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. > 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. Regards Antoine. _______________________________________________ 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