Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171122/d103d8ab/attachment.html below:
<div dir="ltr">On 22 November 2017 at 18:15, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="">On 22 November 2017 at 16:47, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br>
> On 22 November 2017 at 17:43, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
>><br>
>> On 22 November 2017 at 16:30, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>><br>
>> wrote:<br>
>> > On 22 November 2017 at 17:24, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>><br>
>> > wrote:<br>
>> >> Given a comprehension (e.g. list comprehension) is expected to work<br>
>> >> nominally as `constructor(generator expression)`<br>
>> ><br>
>> > As Yury just explained, these two are not equivalent if there is an<br>
>> > `await`<br>
>> > in the comprehension/generator expression.<br>
>><br>
>> As Antoine said, people *expect* them to work the same.<br>
><br>
><br>
> The difference is that a generator expression can be used independently, one<br>
> can assign it to a variable etc. not necessary to wrap it into a list()<br>
> Anyway, can you propose an equivalent "defining" code for both? Otherwise it<br>
> is not clear what you are defending.<br>
<br>
</span></div>[...snip...]<br><div>
<br>
1. List comprehensions expand into nested for/if statements in the<br>
"obvious" way - with an empty list created to start and append used to<br>
add items to it.<br>
  1a. Variables introduced in the comprehension don't "leak" (see below).<br>
2. Generator expressions expand into generators with the same "nested<br>
loop" behaviour, and a yield of the generated value.<br>
3. List comprehensions are the same as list(the equivalent generator<br>
expression).<br></div></blockquote><div><br></div><div>Great, I agree with all three rules.<br></div><div>But there is a problem, it is hard to make these three rules consistent in some corner cases even _without async_.</div><div>For example, with the original problematic example, it is not clear to me how to apply the rule 2 so that it is consistent with 3:</div><div><br></div><div>def fun_comp():<br></div><div>Â Â Â return [(yield i) for i in range(3)]</div><div><br></div><div>def fun_gen():<br></div><div>Â Â Â return list((yield i) for i in range(3))</div><div><br></div><div>I think the solution may be to formulate the rules in terms of the iterator protocol (__iter__ and __next__).</div><div>I will try to think more about this.<br></div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>
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