<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">As you can see, the first code block uses the same parameter name in generator and lambda and works fine, while the second one uses different names and fails with exception, being fine from the point of lambda syntax and semantic view. </span>This inconvinience leads to difficulties in code isolation (lambda writer should know name of the generator parameter, which might be hidden in other subsystem written by other team).</blockquote>

<div><br></div><div class="gmail_extra">Yeah, this is how things currently work. It is not possible to just accept arbitrary parameter name, because generator can consist of several for-loops and have several variables. For example:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">    q = select(g for g in Group if g.dept.number == 44</div><div class="gmail_extra">                 for s in g.students if s.gpa > 3)</div><div class="gmail_extra">

    q.filter(lambda s: s.name.startswith('J'))</div><div class="gmail_extra">    q.filter(lambda g: g.number == 101)</div><div class="gmail_extra"><br></div><div class="gmail_extra">It will be non-intuitive if parameter name can be arbitrary when query has only one for-loop, but becomes non-arbitrary with multiple for-loops.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So yes, filter API requires knowledge of generator variable names, and it may restrict independence of different subsystems. But probably this is not critical if system-wide conventions can be made. For example, "all queries which returns User should use 'u' as a variable name", etc.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">> <span style="font-family:arial,sans-serif;font-size:13px">Is this inconvinience particularly one which you meant, or something other?</span></div><div class="gmail_extra">

<br></div><div class="gmail_extra">Don't remember I said something like that, I spoke purely about performance of INTERSECT / UNION in SQL</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span style="font-family:arial,sans-serif;font-size:13px">As for the intersection, union and subtraction, these functions might be constructed using logic combinations of filter expressions in involved queries instead of using special SQL syntax to implement them IMHO (and that is really what I meant before).</span></blockquote>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-family:arial,sans-serif;font-size:13px">The first two cases might be implemented easy using existent .filter() functionality.</span></blockquote>

<div class="gmail_extra"><br></div><div class="gmail_extra">Although it is doable, I suspect it may be not as easy as it seems, if the goal is to combine expression trees with different variable names. Anyway, thanks for the suggestion, I'll think about it later.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Alexander</div></div>