On Sun, Feb 14, 2021 at 01:31:29AM -0500, Random832 wrote: > > http://www.rosettacode.org/wiki/Function_definition > > That page doesn't really do well at explaining lambda expressions > specifically, omitting it for some languages that definitely have them > [such as Dart].
It's a community site. I'm sure we could fix that if we wanted to and had sufficient Round Tuits. > https://en.wikipedia.org/wiki/Anonymous_function may be better. May be or is? Either way, thanks for the link. > I don't really buy that anyone wouldn't understand what passing > "x=>x+1" as an argument means if they understand the concept of > first-class functions generally. That's not the argument being made. The argument is that people will confuse -> and => and be unsure of the difference, and confuse => with >= comparison operator. I think it is disingenuous to deny that second one when this thread included a good example of a highly experienced, motivated Python programmer mixing up the two symbol. If Paul can do it, we all can. > I still think arrows are the clear winner. I think they're intuitive, > and I think that's *why* C# chose them and why other languages like > Javascript copy them. It wouldn't be the first syntactic feature we'd > have copied from C#. Out of curiosity, which other features are those? I don't think that the argument is specifically about arrows. (Except to the degree that we already have a way to spell anonymous functions, and it isn't clear why we need a second way just to save a handful of characters: lambda a, b, c: a+b*c (a, b, c) -> a+b*c The argument is between the arrow that can be confused with a comparison, versus the arrow that is already used for a closely related concept. In the first case, => will forever be fighting against the much stronger memory trace of >= (I think we can agree that comparisons will be more common than anonymous functions). People's muscle-memory will type >= when they want the arrow; people will wrongly read => as a comparison. And people will ask what the difference is between => and -> the arrow we already have. > > - how many people coming to Python will be familiar with Javascript as > > opposed to R, Julia, Maple, etc, or no language at all? > > I don't really understand why you're bringing up R/Julia/Maple > specifically. Are you advocating for ->? Um, yes. Wasn't it clear enough? > I have no particular > objection to that, but I don't think the difference between two > slightly different looking arrows [one used in C#, Javascript, Scala, > and D; the other used in Java, Kotlin, Julia, R, and Maple] is > particularly difficult. I think either one is just as good as the > other in terms of the meaning being intuitive when reading code. In isolation, sure. But Python already has a forward arrow -> and something that looks like a backward arrow <= but isn't. > > - given how many other things they will have to learn that is different, > > is one comparatively rarely used feature more that much of a burden? > > It's not about being the same to make it easier for people coming from > a particular language. It's being the same because C# (and Javascript) > gets it right, and we should get it right. *semi-wink* Okay, let's do a shoot-out: if we were designing the syntax in isolation (no other languages exist; everyone uses Python) what are the objective advantages and disadvantages of each arrow spelling? * Clearly both -> and => look like arrows. Tie. * Both require the same number of keypresses. Tie. * Similar things should look similar. -> is already used for **return annotations** which is semantically related to **return values** so the use of -> for both concepts strengthens the association of the arrow symbol with returning stuff. * Things which look confusingly similar cause confusion. => looks confusingly similar to -> which will lead to people mixing up the two arrows and asking "what's the difference between ...?" * Things which are dissimilar should look dissimilar. => is very different from >= and <= but they look similar. Every advantage of => is equally shared with -> but => has two disadvantages, and no advantages, compared to ->. So if we're tallying pros - cons for each symbol, I make that: => 2 pros - 2 cons = 0 -> 3 pros - 0 cons = 3 I think this is a slam dunk. If you disagree, can you give some objective pluses for the => symbol that doesn't rely on familiarity with other languages? -- Steve _______________________________________________ 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/XHUU7FMIFTCHQLJGEOP2WVRPGUMGY5NS/ Code of Conduct: http://python.org/psf/codeofconduct/
