<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 May 2018 at 07:59, Angus Hollands <span dir="ltr"><<a href="mailto:goosey15@gmail.com" target="_blank">goosey15@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If, however, the motivation for the PEP was deemed significant enough that warrant its inclusion in a future release, then I would like to suggest that the keyword approach is superior to the operator variant. In particular, I prefer the `where` to the `given` or 'let' candidates, as I think it is more descriptive and slightly shorter to type ;)</div></div></blockquote><div><br></div><div>Aside from an API naming conflict with NumPy, the key problem with using "where" for this purpose is that "where" is explicitly used to name *filtering* clauses in SQL, NumPy, and other contexts ("having" is used in a similar way for filtering on SQL aggregate groups). So in "[(x, y, x/y) for x in data if y where y = f(x)]", having both an "if" clause and a "where" clause makes it look like there are two filters being defined (and a mispelt "==" in the second one), rather than a filter and a name binding.<br><br></div><div>The virtue of "given" is that in any context which uses it, the intended meaning is to associate a name with a value (either directly, as in the mathematical usage, or indirectly, as in the hypothesis API usage), which is exactly the meaning we're interested in here.<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>