<div dir="ltr">Replying out of order:<br><br>[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Under your proposal, that becomes:<br><font face="monospace, monospace">def bench(name, cleanup=None with ???, *, seconds=1, repeat=3):</font><br>except I'm not really sure what goes in the ??? for an empty parameter <br>list.</blockquote><div><br>I know I tend to write long-winded responses, but please read them fully before replying.<br>I covered this.<br><br> [Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But whatever it is, do you still think it is obvious that people <br>will recognise "None" to mean a function without having to backtrack?</blockquote><div><br>It's not clear what you mean by backtracking at this point. <font face="monospace, monospace">cleanup=None with() </font><font face="arial, helvetica, sans-serif">requires no more backtracking than any other compound expression.</font><br><font face="monospace, monospace">cleanup=children.oldest().room</font><font face="arial, helvetica, sans-serif"> doesn't tell you what kind of object is being assigned to </font><font face="monospace, monospace">cleanup</font><font face="arial, helvetica, sans-serif">. Is it a function? Who knows? Even if you know what<br>'</font><font face="monospace, monospace">children</font><font face="arial, helvetica, sans-serif">' is and what the '</font><font face="monospace, monospace">oldest</font><font face="arial, helvetica, sans-serif">' method returns, you still don't know what's being assigned to </font><font face="monospace, monospace">cleanup</font><font face="arial, helvetica, sans-serif"> without reading the entire expression.<br><br>There has never been a guarantee that expressions evaluate left to right simply by virtue of the fact that an order of operations exists. The LL(1) parser limits parsing complexity to expressions which require at most one token look-ahead. Usually (I'll come back to this) that isn't hard for humans who process text in chunks of multiple tokens at a time.<br><br></font> [Steven D'Aprano]<font face="arial, helvetica, sans-serif"><br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And from the threading tests:<br><font face="monospace, monospace">t = threading.Thread(target=lambda: None)</font></blockquote><br><font face="monospace, monospace">t = threading.Thread(target=None with())</font><br><br>seems pretty straight-forward to me.<br><br> [Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">sm = difflib.SequenceMatcher(isjunk=x == ' ' with x, ...)</font><br>The expression x==' ' doesn't look like a function to me.</blockquote><div><br><font face="arial, helvetica, sans-serif">You don't think that perhaps that's because it's brand new syntax? </font><font face="monospace, monospace">x=='' </font><font face="arial, helvetica, sans-serif">doesn't look like a function because it's not a function. You could play the same game with literally any compound expression:</font><br><br><font face="monospace, monospace">>>> func = ", ".join<br><br>", " </font><font face="arial, helvetica, sans-serif">doesn't look like a function to me!<br><br></font> [Steven D'Aprano]<font face="arial, helvetica, sans-serif"><br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> Ideally, we could move that noise out of the way so that the intent is more<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> clearly expressed:</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>So you say.<br>I say it isn't noise, and if you ask me to express my intent, I'll state <br>that it is a function first and at the beginning of the expression, not <br>the end.</blockquote><div><br>Don't you think that depends on the situation at all? Don't you think there are cases where<br>the fact that you're passing a function and the call signature of said function are exceedingly clear from context?<br><br><font face="monospace, monospace">ui_element.on_mousover(<do something> with event)</font><br><br>We already have a way to declare a function signature first. If you think it's paramount, then just def it.<br><br>If you honestly don't understand my position at all. If it's always a surprise to you that ", ".join() takes an iterable of strings<br>or that sorted takes a key-function that takes element from the iterable being sorted, or that on_mousover takes a function that takes an event object<br>etc. etc. etc. then I guess I've never met anyone quite like you. I don't know how to communicate my point of view any better than I already have.<br><br>[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You are judging that from the perspective of someone whose native <br>language makes it easy to say "sorted by foo" (for some value of foo).</blockquote><br>This argument is such a tiring distraction. Please stop. If it's all just random symbols to some non-english speaker, then<br>It doesn't matter either way to them. They can still deal with tokens in the same way as the LL(1) parser. Only one look-ahead.<br>That's not at all how the world works, but I don't have the energy to get into that discussion right now.<br><br>I've been writing a veritable novel on my views on lambda for over a week now and people keep re-tredding the same ground.<br><br>[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We shouldn't judge syntax proposals just on the cases that are carefully <br>chosen to showcase them at their best. Especially not trivial cases.</blockquote><br>We can judge it by examining cases where it might be problematic, but there's no way to keep people from abusing<br>coding constructs to produce unreadable code, so just throwing out random chunks of code like<br><br><font face="monospace, monospace">a.b[c:d]-e**f(g, h=i) + {j & k, l*(m-n(o,p))} with e, k<br></font><br>then saying "looks bad to me" offers no insight into the pros and cons of the proposal. <br>Well, yeah. It looks bad because it's terrible code.<br><br>It feels like you're not even trying to understand the basic premise of my position. Otherwise, I would be delighted to move<br>past the simplified examples and on to more complex and probably troublesome counter examples. Hell, we can talk about how<br>this would effect blind space aliens who can only hear ultra-sonic chirps and are essentially incapable of learning English after we get<br>past this roadblock...<br><br></div></div></div></div></div>