<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 1:36 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Apr 30, 2015 at 11:48:21AM +0200, Todd wrote:<br>
> Looking at pep 492, it seems to me the handling of "for" loops has use<br>
> outside of just asyncio.  The primary use-case I can think of is<br>
> multiprocessing and multithreading.<br>
><br>
> For example, you could create a multiprocessing pool, and let the pool<br>
> handle the items in a "for" loop, like so:<br>
><br>
>     from multiprocessing import Pool<br>
><br>
>     mypool = Pool(10, maxtasksperchild=2)<br>
><br>
>     mypool for item in items:<br>
>         do_something_here<br>
>         do_something_else<br>
>         do_yet_another_thing<br>
<br>
</span><br>
A parallel version of map makes sense, because the semantics of map are<br>
well defined: given a function f and a sequence [a, b, c, ...] it<br>
creates a new sequence [f(a), f(b), f(c), ...]. The assumption is that f<br>
is a pure-function which is side-effect free (if it isn't, you're going<br>
to have a bad time). The specific order in which a, b, c etc. are<br>
processed doesn't matter. If it does matter, then map is the wrong way<br>
to process it.<br>
<br></blockquote><div><br></div><div>multiprocessing.Pool.map guarantees ordering.  It is multiprocessing.Pool.imap_unordered that doesn't.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Of course this sort of thing is possible with iterators and maps today, but<br>
> I think a lot of the same advantages that apply to asyncio also apply to<br>
> these sorts of cases.  So I think that, rather than having a special<br>
> keyword just for asyncio, I think it would be better to have a more<br>
> flexible approach.  Perhaps something like a "__for__" magic method that<br>
> lets a class implement "for" loop handling, along with the corresponding<br>
> changes in how the language processes the "for" loop.<br>
<br>
</span>"async for" hasn't proven itself yet, and you are already looking to<br>
generalise it? Shouldn't it prove itself as not a mistake first?<br>
<span class="HOEnZb"><font color="#888888"></font></span><br></blockquote></div><br></div><div class="gmail_extra">Two reasons:<br><br></div><div class="gmail_extra">1. It may be hard to generalize it later without breaking backwards compatibility.<br></div><div class="gmail_extra">2. Whether it can be generalized or not may have some bearing on whether it gets accepted.<br></div><div class="gmail_extra"><br></div></div>