On Sun, Oct 24, 2021 at 12:44 PM Rob Cliffe <rob.cli...@btinternet.com> wrote: > I'm not keen on the > var = > expr > syntax. IMO the arrow is pointing the wrong way. expr is assigned to var.
That's definitely open to discussion. > Some possible alternatives, if there is no technical reason they > wouldn't work (as far as I know they are currently a syntax error, and > thus unambiguous, inside a function header, unless annotations change > things. I know nothing about annotations): Annotations come before the default, so the question is mainly whether it's possible for an annotation to end with the symbol in question. > var <= exp # Might be confused with less-than-or-equals Not a fan, for that exact reason. > var := expr # Reminiscent of the walrus operator in other contexts. > # This might be considered a good thing or > a bad thing. > # Possibly too similar to `var = expr' This is less concerning than <=, since... ahem. I spy a missed opportunity here. Must correct. This is less confusing or equally confusing as <=, since ":=" is a form of name binding, which function parameters are doing. Not a huge fan but I'd be more open to this than the leftward-arrow. > var : expr # Less evocative. Looks like part of a dict display. (That is precisely the syntax for annotations, so that one's out) > var <- expr # Trailing `-` is confusing: is it part of (-expr) ? Not a fan. I don't like syntaxes where a space makes a distinct difference to the meaning. > var = <expr> # Hm. At least it's clearly distinct from `var=expr`. It took me a couple of readings to understand this, since <expr> is a common way of indicating a placeholder. This might be a possibility, but it would be very difficult to discuss it. > var << expr # Ditto. Like <=, this is drawing an analogy with an operator that has nothing to do with name binding, so I think it'll just be confusing. > (var = expr) > [var = expr] # Ditto Bracketing the argument seems like a weird way to indicate late-binding, but if anything, I'd go with the round ones. > And as I'm criticising my own suggestions, I'll do the same for the ones > in the PEP: > > def bisect(a, hi=:len(a)): # Just looks weird, doesn't suggest anything > to me > def bisect(a, hi?=len(a)): # Hate question marks (turning Python into > Perl?) > # Ditto for using $ or % or ^ or & > def bisect(a, hi!=len(a)): # Might be confused with not-equals Yeah, I don't like != for the same reason that I don't like <= or <<. > def bisect(a, hi=\len(a)): # `\` looks like escape sequence or end of > line > # What if you wanted to break a long line at > that point? No worse than the reuse of backslashes in regexes and string literals. > def bisect(a, hi=`len(a)`): # Backquotes are fiddly to type. Is > ` len(a) ` allowed? Not sure why it wouldn't - the spaces don't change the expression. Bear in mind that the raw source code of the expression would be saved for inspection, so there'd be a difference with help(), but other than that, it would have the same effect. > def bisect(a, hi=@len(a)): # Just looks weird, doesn't suggest anything > to me Agreed, don't like that one. > My personal current (subject to change) preference would be `var := expr`. > > All this of course is my own off-the-cuff subjective reaction. > Y M M (probably will) V. Subjective reactions are extremely important. If the syntax is ugly, the proposal is weak. But I can add := to the list of alternates, for the sake of having it listed. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IZLHGZR6HKLMWH536PSZ6W2UX7KKGLS3/ Code of Conduct: http://python.org/psf/codeofconduct/
