Are better lambdas really impossible?

Ideas
1

Even though I wasn’t around any discussions back then, I vaguely remembered reading that there was some decision made around lambdas being kept the way they are. I searched and found this old wiki page: AlternateLambdaSyntax - Python Wiki which links to an email from @guido:

After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I’ve not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody’s talent and time on an impossible quest.

The rationale for wanting better lambdas (listed on the wiki) still holds today, in my opinion. This was in 2006 and many things have changed since then. Lambda expressions are quite mainstream, and as a result, well understood by many people. Python has also taken directions that were considered “unpythonic” back then.

What were the biggest roadblocks getting this over the goal line?

On the wiki page mentioned above, I see several proposals that could blend pretty well with modern Python. For example, the arrow syntax by Ka-Ping Yee:

a, b, c -> f(a) + o(b) - o(c)
x -> x * x
-> x
*a, **k -> x.bar(*a, **k)
((x=x, a=a, k=k) -> x(*a, **k) for x, a, k in funcs_and_args_list)

or perhaps, to avoid parsing difficulties with type annotations, double arrows:

a, b, c => f(a) + o(b) - o(c)
x => x * x
=> x
*a, **k => x.bar(*a, **k)
((x=x, a=a, k=k) => x(*a, **k) for x, a, k in funcs_and_args_list)
1 Like
2

Tamás Szelei:

[quote]
On the wiki page mentioned above, I see several proposals that could
blend pretty well with modern Python. For example, the arrow syntax by
Ka-Ping Yee:

a, b, c -> f(a) + o(b) - o(c)
x -> x * x
-> x
*a, **k -> x.bar(*a, **k)
((x=x, a=a, k=k) -> x(*a, **k) for x, a, k in funcs_and_args_list)

[end quote]

Sorry, I can’t even tell if that’s supposed to be one example of a
multiline function, or five examples of a single expression function.
The -> x bare arrow is especially confusing to me.

If I recall correctly, Coconut allows arrow notation to define
functions. I’m quite fond of the look, and if we didn’t already have
lambda, I’d probably argue in favour of the arrow over the keyword. (It
is annoying that I can’t use lambda as a variable name.)

But if the body of the function is resticted to a single expression,
then how is it “better” than existing lambda? It’s just a different
spelling:

lambda arg-list : expression

arg-list -> expression

A bit shorter, perhaps a bit more cute, but functionally identical. And
in context, perhaps not so nice to read:

result = sorted(sequence, key=lambda a: a[1])

result = sorted(sequence, key=a -> a[1])

Embedded in an expression, especially a keyword argument, I prefer
having the keyword version.

Given that we have single expression lambda, and backwards compatibility
means that it won’t go away, I don’t think it is worth tinkering with
slightly different spelling for exactly the same thing.

Just painting the lambda bike shed a different colour, just for the sake
of a different colour, is not very interesting to me. But a proposal for
anonymous multi-statement code blocks, like in Ruby, would be much more
interesting. Unless they use braces as delimiters.

Beside, I think that the arrow notation -> or => should perhaps be
reserved for something we currently don’t have, like pattern matching,
not wasted on something we already do have.

1 Like
3

I guess it depends on what you think is “better”. If it’s the lambda keyword you don’t like, sure there are many many ways to get rid of it and make lambdas better for you. But for most contexts I hear this topic in (from people I know), better means whether a new lambda syntax can provide more features (have more than one expression, can contain statements, etc.), and in that case, no, it’s indeed not quite possible.

3 Likes
4

Perhaps I shouldn’t have included that example. The concrete syntax is not really the point of my question. Rather, it’s asking “old” community members what biggest roadblocks were when this was discussed 12+ years ago.

1 Like
5

I think you first need to define what you’re trying to improve: what exactly needs to change and, importantly, why? As the wiki page mentions, all of those proposals were attempts to make the concrete syntax “nicer” to avoid having lambdas removed entirely; since it was decided not to remove them, no change turned out to be needed.

1 Like
6

Sorry, it isn’t really clear to me what answer you are looking for which
isn’t already covered in the wiki and the email thread you linked to.

The roadblocks, then as now, were:

  • convincing skeptics that there is need for new syntax;

  • deciding on acceptable syntax which is backward compatible;

  • getting agreement on all of the above;

  • and doing the actual work to make it happen.

Possibly the only thing that has changed since then is that anonymous
functions have spread out from the functional programming community
and become mainstream, so there are fewer people willing to argue that
there is no need for lambda since we have def.

If you are thinking of resurrecting the debate, we have lambda, and it
does the job it sets out to do. Backwards-compatibility requires that
lambda remains in the language as-is. Given that, it will be hard to
convince anyone that it is desirable to add a second way to spell
exactly the same thing, unless the new syntax brings in something new
like anonymous multi-statement blocks.

Some people don’t know what “lambda” means and have to learn it, but
many thousands of non-native English speaking programmers didn’t know
what “import”, “while”, “raise”, “except”, “await” etc mean and have
had to learn them, so this is not a show-stopper.

Does this answer your question?

7

which isn’t already covered in the wiki and the email thread you linked to

I disagree on that point. The wiki page doesn’t mention any reasons for dropping this effort apart from linking to the decision by @guido; and that email doesn’t provide any justification apart from " so as to stop wasting everybody’s talent and time on an impossible quest". The thread itself is mostly people +1’ing this (literally). So to rephrase my question, the missing information I was looking for is:

  • What made this an “impossible quest” and
  • Is it still “impossible” today

There are plenty of examples in the evolution of Python where new syntax was added to spell exactly the same thing. String formatting went from % to .format to f-strings. filter was largely superseded by generator expressions. I would argue that syntax alone may bring desirable benefits.

The last two points are generally true for any given new feature though, aren’t they? I think even the first one is something that comes up for most features.

8

Tamás said:

[quote]

There are plenty of examples in the evolution of Python where new syntax

was added to spell exactly the same thing. String formatting went from

% to .format to f-strings. filter was largely superseded by

generator expressions. I would argue that syntax alone may bring

desirable benefits.

[end quote]

str.format does more than % formatting, and in turn, f-strings do

more than str.format. They’re not merely a change of spelling.

Generator expressions do more, and are strictly more powerful, than

filter.

Both examples demonstrate the point I’m making: to be accepted, any new

improved lambda will almost certainly need to do more than just being a

new way of spelling the exact same thing.

[quote]

The last two points are generally true for any given new feature though,

aren’t they? I think even the first one is something that comes up for

most features.

[end quote]

Yes, all of those roadblocks are precisely the same roadblocks as for

any other new feature. lambda is no different, except that this is a

feature where many people have an opinion about the colour of the

bikeshed.

As I said earlier, I’m afraid I don’t know what sort of answer you are

looking for. There’s nothing unique or special about lambda

specifically. The roadblocks are the same roadblocks that we would have

if somebody suggested spelling it “throw…catch” instead of

“raise…except”, or “fun” instead of “def”, or adding ^^ as a new

unary operator for len().

I’m sorry, I’m really not trying to be dismissive of your question, I

just don’t get what sort of answer you expect that hasn’t already been

given. Perhaps somebody else might weigh in with a different viewpoint.

2 Likes
9

(Offtopic) Steven, I don’t know how you interact with Discourse, but your comments are coming through with broken formatting - basically plain text with quotes not distinguished from actual text (except for [quote]…[end quote] tags which appear to be malformed as Discourse is not respecting them). Could you please try to see if you can fix your formatting, as your comments are currently almost unreadable. Thanks.

1 Like
11

The impossible quest was for multi-line lambdas, and nothing that made them impossible at the time has changed. (The problem is the ugliness that has to happen at the end of the lambda’s block.)

I think you are approaching this from the wrong end. Unless you have a better proposal, nothing is going to happen, regardless of whether you get answers for those questions. But to come up with a better proposal you’re going to have to do more homework.

PS. I see nothing about the => proposal that’s compellingly better than the current lambda syntax for single-line lambdas, and for multi-line lambdas the problems are exactly the same in either case.

1 Like
12

I think you are approaching this from the wrong end. Unless you have a better proposal, nothing is going to happen, regardless of whether you get answers for those questions. But to come up with a better proposal you’re going to have to do more homework.

ouch, OK - but I’d argue that I’m going at this from the right direction. Figuring out what went wrong before is exactly “doing homework”. How else would I be able to come up with a better suggestion if I didn’t know what was wrong the first time? Thanks for the answers.

13

I don’t know, but you keep arguing intangibles like “Python has also taken directions that were considered “unpythonic” back then” and “There are plenty of examples in the evolution of Python where new syntax was added to spell exactly the same thing.” Those are pretty weak arguments for reopening an old argument.

And by homework I mostly meant learning how Python is parsed and testing your ideas against it.

14

Maybe I mistook the purpose of this forum or this whole site.

15

It is hard for us to say whether you mistook the purpose of this forum
or not, since it is hard for us to guess what you thought the purpose
was.

I don’t know how long you have been using Python, but please understand,
Python is nearly 30 years old, and some of us have been around for ten
or twenty years. Or even all the way back to Day One when Guido first
released Python publicly. Any argument or discussion point people can
come up with about lambda, we’ve heard a dozen times before. And the
arguments don’t get better with repetition, they just get more tedious.

To put it another way, some of us have been hearing arguments about
lambda for longer than others of us have been alive.

If people seem a bit annoyed or frustrated, keep in mind that after
nearly three decades of hearing the same arguments about lambda, they
start to come across as nagging.

I still do not understand what kind of answer you are looking for that
hasn’t already been given. But if it helps, you might consider googling
for “python lambda multiline”:

https://duckduckgo.com/?q=python+lambda+multiline

and similar search terms. You can search Python-Ideas and Python-List:

https://mail.python.org/mailman3/lists/python-ideas.python.org/

https://mail.python.org/mailman/listinfo/python-list

but alas the search facilities are a bit primitive. My recommendation is
to use google or the search engine of your choice to narrow down to a
thread in a particular month and year, then just browser the history.

Guido’s comment about learning about the design and limitations of the
parser may also help. We don’t know how much knowledge you have, so
please feel free to ask questions, the more concrete the better. If you
ask vague or open-ended questions, you will probably get vague and
open-ended answers.

To predict one question you might ask: Python uses an LL(1) parser.

These blog posts may help you understand the culture and design of
Python:

https://www.artima.com/weblogs/viewpost.jsp?thread=147358

16

I don’t know if you did. But Guido gave you some pretty explicit answers:

  • Multi-line lambdas remain impossible (none of the problems raised at the time have changed).
  • For single-expression lambdas, unless you have a better proposal, nothing is likely to change.
  • There’s no compelling advantage in the => proposal, so “status quo wins” is going to be the conclusion here¹

Finding a “better proposal” needs work - research into what was proposed in the past, and why those proposals weren’t good enough. Asking for information here is fine, but you need to be prepared for the fact that most people simply aren’t interested enough any more to go over that ground again - if you are, then you will quite probably have to do the work yourself. (If you don’t want to do so, that’s perfectly fine, but you have to then accept that “nobody who thinks there is a solution is willing to do the work” might be the ultimate reason here).

Yes, but that doesn’t mean they are irrelevant here. To the contrary, the implication is that if you can’t address even these completely general issues with whatever proposal you make, then there’s little or no chance that you’ll get anywhere even if you deal with the more specific features related to lambdas.

Someone needs to make a proposal. You haven’t (yet). By focusing on the meta-question of whether it’s worth making a proposal at all, you are only going to get meta-answers like “everyone is fed up with debating this, so no-one is interested”, and “no-one wants to go over all the old arguments, so anyone making a new proposal has a huge load of research to do, which nobody is interested in helping with”.

On reflection, maybe you have mistaken the purpose of this group. It’s about discussing proposals for language changes, not so much for discussing whether it’s worth having such discussions. People are tolerant, though, so higher level questions aren’t forbidden. But at some stage, you will get asked to come up with an actual proposal if you want to take things further. Asking “how should I go about researching and presenting such a proposal so that it won’t get rejected out of hand based on an old decision that better lambdas aren’t worth debating?” is reasonable, but you’ve had some answers to that question (do a lot of research, and make sure you’ve addressed all of the points previously covered - plus, make sure your proposal is interesting to a community who are frankly fairly tired of the subject) - whether you want to do what’s been suggested and put together a proposal on that basis is up to you, really.

¹ If you’re not clear why status quo wins, Steven provided a link that covers this, but basically changing something that would affect literally millions of programmers needs a fairly strong justification.

17

I still do not understand what kind of answer you are looking for that
hasn’t already been given.

I did not say I wasn’t given an answer, and in fact I got some pretty good information. My later posts were reactions to the specific answers here. Thanks for the further specifics. I understand now that the big problem is finding a syntax for multiline lambdas that fit into the language. So I think this topic can be closed (I don’t appear to have that power, so if an admin sees this, please close it).

If people seem a bit annoyed or frustrated

I wasn’t going to address this myself, but since your brought it up: I do feel that people in this thread read a lot more into what I was asking and I did feel a tad bit unwelcome here. I can empathize with this frustration, given the existence of past tedious discussions. However, there was no straightforward way for me to know how loaded this topic was. I did some research and I’ve shown that in my starting post - I asked specific questions that I could not find the answer for in the sources that I stumbled upon.