Message300517
| Author |
syncosmic |
| Recipients |
ncoghlan, syncosmic, yselivanov |
| Date |
2017年08月18日.16:58:21 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1503075501.35.0.560187361569.issue31230@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I like where this is heading! Aside from the cleaner patterns for handling these objects, I think it'll make it a little easier for people who are just starting to use asynchronous objects in Python (e.g. me) to grasp what's similar about them.
+1 that `__async_call__` could be confusing, for the general reason you mention, but in particular because it would look exactly analogous to `function.__call__()` (what the French call a "faux ami").
A not-thought-out alternative: what about noun-ing the verbs into `__async_calls__` and `__async_returns__` (or maybe `__async_returns_to__`)?
BTW, I was thinking of taking a quick run at bpo-31197 while this simmers. I don't /think/ that risks being eventually mooted by these changes; if anything, it might be easier to adapt `dis` to this proposal if that refactoring has already been done. LMK if you think that's the wrong order, though. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年08月18日 16:58:21 | syncosmic | set | recipients:
+ syncosmic, ncoghlan, yselivanov |
| 2017年08月18日 16:58:21 | syncosmic | set | messageid: <1503075501.35.0.560187361569.issue31230@psf.upfronthosting.co.za> |
| 2017年08月18日 16:58:21 | syncosmic | link | issue31230 messages |
| 2017年08月18日 16:58:21 | syncosmic | create |
|