On Wed, Jan 9, 2013 at 6:31 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday <yorik....@gmail.com> > wrote: > > 4. Why separate exception() from result() for Future class? It does the > same > > as result() but with different interface (return instead of raise). > Doesn't > > this violate the rule "There should be one obvious way to do it"? > > The exception() method exists for the same reason that we support both > "key in mapping" and raising KeyError from "mapping[key]": sometimes > you want "Look Before You Leap", other times you want to let the > exception fly. If you want the latter, just call .result() directly, > if you want the former, check .exception() first. > Ok, I get it now. Thank you for clarifying. > Regardless, the Future API isn't really being defined in PEP 3156, as > it is mostly inheritied from the previously implemented PEP 3148 > (http://www.python.org/dev/peps/pep-3148/#future-objects) > Then #3 and #4 are about PEP 3148. Why was it done this way? Kind regards, Yuriy.
_______________________________________________ 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
