On May 23, 2010, at 9:43 AM, Jeffrey Yasskin wrote: > I think the PEP's overall API is good to go. > > On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan <brian at sweetapp.com> > wrote: >> >> On 22 May 2010, at 23:59, R. David Murray wrote: >>> If there is still discussion then perhaps the PEP isn't ready for >>> pronouncement yet. At some point someone can decide it is all >>> bikeshedding and ask for pronouncement on that basis, but I don't >>> think it is appropriate to cut off discussion by saying "it's >>> ready for >>> pronouncement" unless you want increase the chances of its getting >>> rejected. >> >> Here are the new proposed non-documentation changes that I've >> collected (let >> me know if I've missed any): >> >> ... > > I propose to rename the Future.result method to Future.get. "get" is > what Java (http://java.sun.com/javase/7/docs/api/java/util/concurrent/Future.html > ) > and C++ (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf > section 30.6.6 para 12) use, and the word "result" doesn't seem > particularly better or worse than "get" for our purposes, which > inclines me to stay consistent. In C++ and Java, there is only one result-retrieving method so "get" seems like a reasonable name. My implementation has a second method .exception(), which returns the exception raised by the submitted function (or None if no exception was raised). I thought that having multiple getter methods, where one is called .get() would be a bit confusing. But I don't really care so I'm -0. Cheers, Brian
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