A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2013-January/123536.html below:

[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted [Python-Dev] PEP 3156 - Asynchronous IO Support RebootedBenjamin Peterson benjamin at python.org
Wed Jan 9 04:02:20 CET 2013
2013/1/8 Benjamin Peterson <benjamin at python.org>:
> 2013/1/8 Guido van Rossum <guido at python.org>:
>> On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson <benjamin at python.org> wrote:
>>> 2013/1/8 Yuriy Taraday <yorik.sar at gmail.com>:
>>>> 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"?
>>>
>>> I expect that's a copy-and-paste error. exception() will return the
>>> exception if one occured.
>>
>> I don't see the typo. It is as Nick explained.
>
> PEP 3156 says "exception(). Difference with PEP 3148: This has no
> timeout argument and does not wait; if the future is not yet done, it
> raises an exception." I assume it's not supposed to raise.

Oh, I see. "it raises an exception" refers to the not-completed-eyt
exception. Poor reading on my part; never mind.



-- 
Regards,
Benjamin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4