[Chris Angelico] > Python's parser is *deliberately* incapable of backtracking this far > in its definition of syntax.
Can you explain how far the parser is capable of backtracking? It seems like <expression> with <signature> would require a similar amount of backtracking to ternary expressions: <expression> if <condition> else <expression> If the preceding expression is the same in both cases, then the parser needs to backtrack just as far when it finds an "if" as when it finds a "with". [Chris Angelico] > You then said that it was the parameter "key" that told you that > this would be a function, which is also unacceptable in Python syntax. That was *never* a statement about syntax. It was about the context clues a reader has, not the parser. The proposed syntax: <expression> with <signature> is an expression that evaluates to a function object regardless of any parameter or any function it might or might not be passed to. My argument is simply: Most cases where an anonymous function is more expressive than a named function are also cases where, *from the perspective of a human reading the code*, the signature is noisy preamble that gets in the way of the expression. In psuedo code, people tend to write things like: >>> hand = sorted(cards, by=card.suit) Obviously that wouldn't compile because the computer doesn't know what "card" is. However; >>> hand = sorted(cards, by=lambda card: card.suit) puts a bunch of noise that's mostly of interest to the computer in front of the expression that's of interest to the reader. There is precedent for late-variable-binding in Python expressions already (e.g. comprehensions), so it makes sense to me that the expression version of function declaration could also bind the signature after the main expression. The same logic follows for mappers, reducers, filters, callbacks, event-handlers, etc. [Chris Angelico] > So how do you intend to do this? I don't intend any of this to make its way into Python. It's a case study of expression design. It's interesting to me to explore such alternatives. It's fine to prod it and examine its flaws as Jonathan Fine has. [Chris Angelico] > And you still haven't done anything to show that this is actually > better than "lambda card:" I'm trying to, but I also have to answer all your misconceptions about the idea (like that the syntax is function or parameter-dependent). [Chris Angelico] > I'm done. OK. I'm sorry if I upset you.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
