LWN: Comments on "Alternative syntax for Python's lambda"

Alternative syntax for Python's lambda

flussence — Sun, 18 Apr 2021 10:28:44 +0000

>Does anyone want to be where Raku is today?

It's the easiest way today (and for the past 6 years or so) to run Python 2 and 3 code in an environment with modern quality-of-life features like arrow functions, switch statements and threads. I'm sure there's demand for that somewhere.

Alternative syntax for Python's lambda

hummassa — Fri, 16 Apr 2021 11:02:42 +0000

Raku is actually an useful language to learn and use today. Yes, it does not have the (deserved) place in the pantheon that Python has. It has to maturate its tools (yay more compiler optimizations) and its frameworks. I use it regularly, and with nice results on my field (data integration and analysis).

Alternative syntax for Python's lambda

wtanksleyjr — Thu, 15 Apr 2021 20:20:57 +0000

Does anyone want to be where Raku is today? Or for that matter where Perl plus Raku is today? Perl has lost steam since 2005-ish, and Python only just stepped up circa 2018. Python didn't eat Perl's lunch; it looks like something that's internal to Perl itself.

Alternative syntax for Python's lambda

mina86 — Wed, 31 Mar 2021 20:53:13 +0000

> but it led "Random832" to suggest looking at the "->" or "=>" arrow
> operators used by other languages, such as C#, Java, and JavaScript.

>> It's worth noting that all three of these are later additions to
>> their respective languages, and they all have earlier, more
>> difficult, ways of writing nested functions within
>> expressions. Their designers saw the benefit of an easy lambda
>> syntax, why don't we?

I don’t know about C# but before lambda functions were introduced in
Java, one had to write dozens of lines to get a simple anonymous ‘x+y’
function. This is nothing like Python which has a short lambda
expression.

And as for JavaScript, arrow functions have different semantics than
anonymous functions. The arrow function wasn’t introduced because
‘function’ is such a long word but because programmers couldn’t
comprehend how ‘this’ variable worked. Again, this does not reflect
situation in Python.

Neither comparison is apt.

Alternative syntax for Python's lambda

quantzur — Fri, 26 Mar 2021 14:29:33 +0000

The lambda function still doesn't know it's own name:

>>> def g(x): return x * 7
...
>>> g(4)
28
>>> g.__name__
'g'
>>> list(map(f := lambda x: x * 7, [1, 2, 3]))
[7, 14, 21]
>>> f(4)
28
>>> f.__name__
'<lambda>'

Alternative syntax for Python's lambda

strombrg — Thu, 25 Mar 2021 20:06:48 +0000

I'm opposed to terse-ifying lambda in Python.

Lambda is rarely useful in Python - you're almost always better off using a generator expression, a list comprehension, or something from the operator module.

And lambdas tend to give rise to the software development equivalent of a runon sentence.

Naming a function in those rare cases that you genuinely need something custom really isn't the end of the world, and is more readable anyway.

Alternative syntax for Python's lambda

nix — Wed, 24 Mar 2021 00:00:58 +0000

Actually, a reference or two might be helpful. I've not really looked at the changes in C++ and what they imply for typical style since about 2000, and the language has moved on. I ought to catch up, but the relevant content appears to be scattered across hundreds of webpages each of which assumes you have read all the others first.

If there really is a book somewhere discussing how C++ has changed and how typical style has changed, I'd be very interested, because modern C++ has at some point since C++11 dissolved for me from "I can kind of read this if I squint" to "this is a pile of angle brackets and I really have no idea why they are here rather than somewhere else". So I think I have some relearning to do -- but from where?

Alternative syntax for Python's lambda

kpfleming — Tue, 23 Mar 2021 00:27:16 +0000

Yes, this exactly. It's trivially easy to accidentally capture 'this' in a lambda without extending the lifetime of that object.

Alternative syntax for Python's lambda

zlynx — Mon, 22 Mar 2021 21:31:18 +0000

He probably means how you can define a C++ automatic reference capture lambda, then when it has a lifetime longer than those references the world blows up.

Java's garbage collection has a similar problem here though. Instead of exploding, your "innocent and harmless" capture holds a 300 MB data structure live in RAM.

I've seen C++ lambda captures hold references after a function exits, after a thread exits and even after the program itself exits. Threads continue running even after static object destruction.

Alternative syntax for Python's lambda

hummassa — Mon, 22 Mar 2021 16:52:02 +0000

Whoah? There is nothing but automatic memory management in C++, unless you are using new and delete, in which case I have a stack of books for you to read before you start over.

Alternative syntax for Python's lambda

hummassa — Mon, 22 Mar 2021 16:11:51 +0000

<Ctrl+k>*l

:help digraphs

Alternative syntax for Python's lambda

flussence — Mon, 15 Mar 2021 07:37:50 +0000

A delayed language will eventually be good; a language that gets rushed to meet nonsense deadlines will become the legacy code everyone curses for decades to come.

The most baffling thing to me about the whole epic of Raku isn't how it concluded, but that as recently as last week I still see people who think they're clever for regurgitating hateful Perl 6 FUD from the era when it was still called Perl 6, Slashdot was a relevant tech site, and comparisons to Duke Nukem Forever were still valid. The language is a good tool to write in, but it's accidentally just as valuable for its ability to quickly expose the sort of people with ossified brains and odious worldviews most of us wouldn't want anything to do with.

Alternative syntax for Python's lambda

cbensf — Sun, 14 Mar 2021 12:49:43 +0000

Both would be valid choices in a fresh language, but in Python a lot of other choices have fallen into place to work better with them as functions.

* map() and filter() should work on any iterable. In Ruby calling them as methods works by all iterables inheriting the Mixin `Enumerable` which keeps growing with time.
But in Python the iteratable/iterator protocols are frozen and extremely narrow. All you need is `__iter__` / `__next__`. This is a feature.
Consider `itertools` module — it extends the set of things you can do with iterators simply by exporting more functions, without adding methods to built-in types. Similarly, countless people have written functions processing iterators, sharing some on PyPI.
[To be fair, *in practice* the Ruby culture of monkey-patching causes surprisingly little problems! So it's more cultural choice than technical argument.]

* There is also a question of symmetry when consuming several iterables, e.g. `zip(foos, bars)` or even the little-known `map(operator.add, foos, bars)`. These would look less pretty as methods on the first sequence...

* There are also various builtins "reducing" an iterable like `sum()`, `all()`, `any()`, `max()` etc. that combine pleasantly with generator expressions. E.g. to test if `n` is composable prime: `any(n % d == 0 for d in range(2, n))`.
In ruby this would be `(2...n).any? { |d| n % d == 0 }` which is a method on Enumerable that takes a block; so in Python this pattern of functions taking an iterator compensates for lack of blocks in some cases...

* A deeper argument IMHO, is that Python has a long tradition of separating the protocol a class has to implement from the public interface one calls.
It does this by operators and global functions, which adds flexibility and helps evolve the language:
- `a < b` operator started out in python 2 calling `a.__cmp__(b)` with fallback to `b.__rcmp__(a)`; later PEP 0207 added `a.__lt__(b)` and `b.__ge__(a)`.
- `bool()` checks `.__nonzero__()_` but falls back to `.__len__()`.
- `iter()` supports objects without `.__iter__` if they implement "sequence" protocol of `.__getitem__` with increasing integers. This allowed the for loop, but also everything else that wants to iterate, to keep working with older classes predating the iterator protocol.
- Even the trivial `.next()` method was wrapped in a builtin function `next()`, which helped abstract the later renaming to `.__next__` (PEP 3114).

Alternative syntax for Python's lambda

HelloWorld — Sat, 13 Mar 2021 13:53:14 +0000

Or one can just use one of the myriads of languages that got this right a decade or two ago (or 7 in the case of Lisp).

Alternative syntax for Python's lambda

kleptog — Thu, 11 Mar 2021 08:35:12 +0000

Well, in Elixir (which I think lifted the syntax from Ruby) it would look like:

range(5) |> zip(reversed(range(5)) |> map(lambda x, y: x + y)

Underwater this is converted to:

map(zip(range(5), reversed(range(5)), lambda x, y: x + y)

There is something pleasing about having the operator between the operands, but I don't think Python should go this route. It requires your entire standard library to be designed to make this work well. It's most appropriate for functional languages.

Alternative syntax for Python's lambda

fredrik — Wed, 10 Mar 2021 11:28:26 +0000

In Gnome, and terminals like Alacritty, you use the generic unicode character shortcut, which is Ctrl + Shift + u followed by the unicode code point for lambda which is 03BB, which can be abreviated to 3bb, so basically:

Ctrl + Shift + u 3 b b Space

Easy as pie! 🙂

Alternative syntax for Python's lambda

anselm — Wed, 10 Mar 2021 09:36:35 +0000

And C++ is one of the most successful languages of all time.

C++: The COBOL of the 1980s.

Alternative syntax for Python's lambda

mpr22 — Wed, 10 Mar 2021 09:12:50 +0000

.... personally, I think the answer should be "the ugaritic cuneiform one" :D

Alternative syntax for Python's lambda

pj — Wed, 10 Mar 2021 03:50:31 +0000

I use kitty as a terminal and have a hotkey for unicode input where I can then type in the long name and choose it from a list. This brings up... which lambda?

U+39b is greek capital lambda
U+3bb is greek small letter lambda
U+1d27 is greek letter small capital lambda

...or one of the other 10ish mathematical lambda characters? (list at https://unicode-table.com/en/search/?q=lambda )

Is there a convention for this? is one more canonical than the others?

Alternative syntax for Python's lambda

milesrout — Wed, 10 Mar 2021 02:43:09 +0000

The first solution is entirely doable. It's not hard to formally specify how indentation and whitespace inside indentation-insensitive expressions would work in a way that is quite intuitive, and where writing something that doesn't parse gives you an *error* instead of failing silently.

The way it works currently in Python (or at least you can conceptualise it this way to produce exactly the same result) is that the scanner/lexer parses each token, including whitespace tokens. Then it joins 'continuation lines' joined by backslashes, determines initial whitespace at the beginning of each line and then basically deletes the remaining whitespace, converting it into newline, indent and dedent tokens. Then any indent/dedent/newline tokens inside parens are deleted, so that this continues to work:

x = foo(1,
    2)

That's seen by the parser as

x = foo ( 1 , 2 ) NEWLINE.

not as

x = foo ( 1 , NEWLINE INDENT 2 ) NEWLINE DEDENT.

It would be quite simple: mark every newline and indent within a particular depth of bracketing with that depth, and then ignore any indents of greater depth than the current level of bracketing while parsing, and insert virtual dedent tokens when going down levels of nested bracketing.

so that would be

x = foo ( 1 , NEWLINE1 INDENT1 2 DEDENT1 ) NEWLINE

so if you had in fact written

x = foo(if True:
          2
        else:
          3)

you'd get

x = foo ( if True : NL1 IN1 2 NL1 DE1 else : NL1 ID1 3 NL1 DE1 ) NL1

From the perspective of whatever is parsing at the top level, that's:

x = foo ( [arbitrary tokens] ) NL

and from the perspective of whatever is parsing inside the parens, that's:

if True : NL IN 2 NL DE else : NL ID 3 NL DE

which is exactly what you get if you parse that statement at a top level in Python currently (at least conceptually):

if True: # if True : NL
    2 # IN 2 NL
else: # DE else : NL
    3 # IN 3 NL
# DE

It's also really easy to implement. I have done so myself as a proof of concept, which I later turned into the parser for a scripting language that is basically Python-with-multi-line-lambdas. It's a few extra lines in the scanner and a few extra lines in the parser. It doesn't slow anything down from a computational complexity perspective. And as a bonus, it gives you a hard error rather than silently-do-the-wrong-thing if you get nested indentation wrong.

I know it's a really popular meme in the Python community that it's OMG2HARD4ME to do multi-line lambdas in a way that gives intuitive, hard-to-get-wrong do-what-I-mean results and is easy and efficient to implement, but as far as I can tell it's just not true.

It would be massively useful. It wouldn't just give multi line lambdas, it would give the ability to nest any expression inside any other expression. All the Python special cases, like generator expressions (just use (for x in y: f(x))), a if b else c (just use a proper if statement, although that would be forced to be on at least 2 lines), etc. could be deprecated and phased out eventually.

Of course it will never happen in Python because it's remarkable conservative about syntax that actually matters while wildly liberal with making relatively useless syntax changes like :=. [You could just write foo((x = 1)) with my suggestion, by the way, which is a far nicer way of doing it than :=...]

Alternative syntax for Python's lambda

milesrout — Wed, 10 Mar 2021 02:08:58 +0000

The font faces we use today are not very much like the characters developed for convenience when writing "using quill pens on animal-skin parchment". Letter forms change drastically with every new medium of writing. When symbols were chiseled into stones you get sharp and angular runes. When symbols are pressed into clay with a stylus you get wedge-shaped cuneiform. When symbols are painted onto paper with brushes you get the calligraphic Chinese script. When symbols are painstakingly carved into elaborate burial chambers you get the exquisite Egyptian hieroglyphs. When the same symbols are hastily jotted onto papyrus with a reed pen you get hieratic.

When symbols are carved into a wax tablet you get what became our UPPERCASE latin alphabet, generally big sharp uncomplicated lines. When the same symbols are drawn onto a parchment or papyrus with a pen, you get the old Roman cursive, which basically became our lowercase.

The letterforms in modern fonts aren't even that similar to the script/cursive forms people use in handwriting today (see 'a' or 'g').

I honestly believe that programmers would use more unicode symbols if the input methods were better. Is that actually a good thing? There are a lot of Unicode confusables after all...

Alternative syntax for Python's lambda

milesrout — Wed, 10 Mar 2021 01:44:28 +0000

>I'd prefer them to be methods rather than functions.

This is not and will never be a good idea. So-called 'UFCS' proposals have failed repeatedly in C++ for good reason, and in Python. Standalone functions are not methods and the method syntax is ugly and misleading. Prioritising one argument over others nearly always makes no sense, and even when it does it's rare that it would be the first argument anyway. Why would it be `foo.map(lambda: ...)` or `foo.map(lambda: ..., bar)` and not `(lambda: ...).map(foo)` or `(lambda: ...).map(foo, bar)`?

I think that it is obvious that we should stick to calling functions as `f(x, y, z)` as we have done in many programming languages for decades and in mathematics for hundreds of years. `x.f(y, z)` makes no sense. `a.plus(b)` is just hideously ugly compared to `plus(a, b)`, and it's totally backwards anyway. If you were going to change to anything it should be `a b plus`, as then at least things would be evaluated entirely left-to-right.

Alternative syntax for Python's lambda

milesrout — Wed, 10 Mar 2021 01:38:06 +0000

>Python 2.7 reached its enormous popularity for being a great balance of complexity and ease of use, which led to PyPI, and it's current status of tool-of-choice for a massive number of programmers. But there were a couple of warts that just annoyed people enough that it was decided to break things, just this once, to fix them.

This is revisionist nonsense. Python 3 development was started long before Python 2.7 existed. PyPI dates back to at least 2003, before Python 2.4 was released, let alone 2.7 (which wasn't released until 2010, seven years later). Meanwhile, Python 3 was first officially released in 2008, but had been floating around as an idea since at least 2006 if not earlier. PEP3000 dates to April 2006, and---as far as I know---was not the first suggestion of a backwards incompatible Python release.

Alternative syntax for Python's lambda

NYKevin — Tue, 09 Mar 2021 17:32:35 +0000

How would you propose we rewrite the following?

map(lambda x, y: x + y, range(5), reversed(range(5)))

I'm not sure that range(5).map(lambda x, y: x + y, reversed(range(5))) is an improvement. And I'm definitely not writing zip(range(5), reversed(range(5)).starmap(lambda x, y: x + y), because that's just ridiculous.

Alternative syntax for Python's lambda

NYKevin — Tue, 09 Mar 2021 17:07:02 +0000

The problem with that is, if you accidentally have any value to its immediate left, then it already parses as a very different expression:

>>> import ast
>>> print(ast.dump(ast.parse('z |x, y| x + y - 2', mode='eval'), indent=4))
Expression(
    body=Tuple(
        elts=[
            BinOp(
                left=Name(id='z', ctx=Load()),
                op=BitOr(),
                right=Name(id='x', ctx=Load())),
            BinOp(
                left=Name(id='y', ctx=Load()),
                op=BitOr(),
                right=BinOp(
                    left=BinOp(
                        left=Name(id='x', ctx=Load()),
                        op=Add(),
                        right=Name(id='y', ctx=Load())),
                    op=Sub(),
                    right=Constant(value=2)))],
        ctx=Load()))

(The indent= argument to ast.dump() requires Python 3.9+ for pretty-printing.)

That's not necessarily a complete non-starter, seeing as the lambda syntax probably would not allow you to put a value there, but it would be awkward if a small typo (e.g. omitting a comma) would result in a parse like that. Unfortunately, you can't just say "Well, x and y are non-existent variables, so don't parse it like that." An unrecognized variable is currently interpreted as an uninitialized global; it's assumed that said global will exist by the time the function is actually called (or else it's a runtime error). Python needs to continue to support that use case, or else recursive function calls won't work (functions are "just" variables that point at function objects).

Alternative syntax for Python's lambda

nybble41 — Mon, 08 Mar 2021 23:17:07 +0000

> On KDE, systemsettings allows you to pick a key to use as XComposeKey.

Yes, that's how I have it configured. In other desktop environments you can use "setxkbmap -option compose:menu" (plus your normal model/layout options) for the same effect.

> I don't think the env vars you are exporting are needed.

If you don't set them then both Gtk and Qt will pick a default input method. If that happens to be XIM then everything will work just fine. If not, the .XCompose file might be ignored; it depends on which input method was chosen. IBUS has some support for reading .XCompose in recent versions. I'm not sure about the others.

Alternative syntax for Python's lambda

msuchanek — Mon, 08 Mar 2021 12:16:46 +0000

Somewhat off-topic, but to me, the syntax of map and filter is a bigger issue than lambda. I'd prefer them to be methods rather than functions.

This is pretty hard for me to read:

>>> map(lambda x: x + 1, range(5))

The lambda blends into the arguments and the comma is weak as a visual separator.

This would much easier:

>>> range(5).map(lambda x: x + 1)

Could that be partly to blame for the complaints about the lambda syntax?

Alternative syntax for Python's lambda

marcH — Sun, 07 Mar 2021 00:15:00 +0000

Maturity: when you ran out of important things to do and finally have time to discuss pointless changes.

Alternative syntax for Python's lambda

Deleted user 129183 — Sat, 06 Mar 2021 15:23:33 +0000

> There's a point where you need to start working on a new language
> I would love to have a Python 4.0 which is a feature freeze of Python 3.x, and the announcement of Snake-0.3b1: like Python but with X and Y and also Z!

Erm…

*looks at ~Perl 6~ Raku*

I don’t think that it’s actually a great idea.

(and I mean its adoption, not the language itself)

Alternative syntax for Python's lambda

LtWorf — Sat, 06 Mar 2021 09:55:06 +0000

On KDE, systemsettings allows you to pick a key to use as XComposeKey.

I don't think the env vars you are exporting are needed. I do not have them.

It used to be that GTK did not support longer sequences than 2 so I had to write them in kwrite and copy paste, but it seems to be working now for a while.

Alternative syntax for Python's lambda

marcH — Sat, 06 Mar 2021 07:04:17 +0000

> Having these things as words gives us words to talk about them and I don't have to know if it's an arrow or a pointer or a cursor.

... and for that reason everyone and will keep calling the new arrow notation... "lambda"! So much for "beginner-friendliness".

The beginner-friendly name is "anonymous function" but good luck getting non-beginners used to something that long.

> > > [It's] no more "magic" than tuple, deque, iterator, coroutine, ordinal, modulus, etc, not to mention those ordinary English words with specialised jargon meanings like float, tab, zip, thread, key, promise, trampoline, tree, hash etc.

Nice one.

Alternative syntax for Python's lambda

aeline — Sat, 06 Mar 2021 07:03:38 +0000

I agree I really like this syntax (although I think Ruby had it first)
It feels very visually distinct from tuples, which I think is plus.

Alternative syntax for Python's lambda

aeline — Sat, 06 Mar 2021 01:54:02 +0000

DrRacket also allows most unicode, by typing \latexcode and pressing Cmd-Enter.
This is really nice for following mathematics/language papers. A snippet from a recent project:
;; Values
(v ::= n
b
∅ ;; Unit
(λ (x : t) e) ;; Value Abstraction
(Λ x e)) ;; Type Abstraction

Alternative syntax for Python's lambda

aeline — Sat, 06 Mar 2021 01:49:35 +0000

In emacs and DrRacket that hotkey Cmd-\

Alternative syntax for Python's lambda

mbunkus — Fri, 05 Mar 2021 23:58:09 +0000

While not built-in, I've been using the nice little Open Source program WinCompose[1] for quite a while now on Windows. It's easily configurable, both regarding the sequences as well as the key to use as the compose key, and it comes pre-configured with a wide range of sequences, a lot of which match the traditional XCompose sequences.

[1] http://wincompose.info

Alternative syntax for Python's lambda

flussence — Fri, 05 Mar 2021 22:13:01 +0000

If Python starts a clean break and major refactoring to clean up 3.x's myriad gobbledygook syntax extensions right now, using all the resources and prior art available to them, then it'll be caught up to where Raku is today in significantly less time than the 20 years of effort that took. Maybe optimistically it'd be 5 years. *If*.

If it doesn't, well… people already complain that it's the new Fortran but at this rate it's going to be the new PHP too. Looking forward to that next “fractal of awfulness” blogpost…

Alternative syntax for Python's lambda

mpr22 — Fri, 05 Mar 2021 21:43:45 +0000

I use LeftWin for Compose myself. It's a lot easier to reach fluidly than Menu on a standard-pitch 104/105 key keyboard.

Alternative syntax for Python's lambda

nybble41 — Fri, 05 Mar 2021 21:35:14 +0000

I type λ using the XCompose input method. That's with this entry in my custom .XCompose file[0]:

<Multi_key> <g> <r> <l> : "λ" U03BB # GREEK SMALL LETTER LAMBDA

Here are the equivalents for lowercase a-z: αβ_δεφγηιθκλμνοπχρστυ_ωξψζ ('c' and 'v' have no corresponding entries and so were replaced with '_').
And the equivalents for uppercase A-Z: ΑΒ_ΔΕΦΓΗΙΘΚΛΜΝΟΠΧΡΣΤΥ_ΩΞΨΖ.
Also many useful symbols: → ⇒ ↑ ↓ × ÷ « » ⋄ ⊛ Ⓧ ¾ ⅞ ☺ € ₡ ¢ ∀ ∃ ±

Unfortunately Windows doesn't have any built-in equivalent to XCompose. I have a few char codes memorized for that, but λ isn't one of them.

To make this work under Linux with X11 you need to create the file ~/.XCompose, set GTK_IM_MODULE=xim and QT_IM_MODULE=xim, and assign some key to the Multi_key function in your keyboard settings. I use the Menu key for Multi_key but you might prefer something else.

[0] https://jessemcdonald.info/gogs/nybble/compose-config/raw...

Alternative syntax for Python's lambda

cpitrat — Fri, 05 Mar 2021 19:39:07 +0000

Stupid question: how do you type it? Do you configure your editor to have a special shortcut? Do you know the char code by heart?

Alternative syntax for Python's lambda

amarao — Fri, 05 Mar 2021 19:18:27 +0000

Can't we use rust notation for closures? |x, y| x + y - 2?

Rust has second form for closures with {}, but we can ignore those.