That single comment from Guido 15 years ago, which was largely backtracked on—map and filter remain in the core library and reduce moved to a library in stdlib, lambda remains—is not really an example of something accurately described as “increasingly” now. In fact, given the backtracking, it's arguably decreasingly true from the high point of that post.
let x = foo in expr
can be [expr for x in (foo,)][0]
(kinda reads like a Haskell `where` clause!) or: (lambda x = foo: expr)()
useful in a pre-walrus-operator REPL :)You would not get through code review with that in any shop that has discipline.
... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production.
PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp:
[
y+y
for x in my_list
for y in (foo(x),)
]
but it's (obviously) ugly & only useful if you're in a REPL and don't want to rewrite the whole thing.> "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this."
so it's just keeping in line with Python's general imperativess.
> FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé
i, on the other hand, do think it's a bad thing :) but what can you do...
Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days.