[Python-ideas] Does jargon make learning more difficult?

[Abe Dillon]

[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180821/417c8e88/attachment.html>