5 ms·
If you want a multi line lambda: def print_each_twice(xs): map(lambda x: print(x) # whoops, impossible You can define a local function: def p
by rjeli 9y ago
If you want a multi line lambda:
def print_each_twice(xs):
map(lambda x: print(x) # whoops, impossible
You can define a local function:
def print_each_twice(xs):
def print_twice(x):
print(x)
print(x)
map(print_twice, xs)
The former is more intuitive to write. The latter reduces nesting, makes you name the function, and improves readability IMO. It's currently easy to scan blocks of Python and see each indentation level starting with one of a few keywords (class, def, for, with). Adding multi line lambdas would make the ultra simple structure harder to quickly parse.
- KirinDave 9y ago> If you want a multi line lambda: I don't want this though. This doesn't do what multi-line lambdas do. It can never do what lambdas do. It's not a lambda function if it's named and fully pre-computed. > Adding multi line lambdas would make the ultra simple structure harder to quickly parse. This is just about the least compelling argument I've ever heard. "The parser writers are not going to have fun."
- rjeli 9y agoI meant to parse mentally. Control flow in Python is very easy to mentally parse at a glance. Powerful lambdas get rid of that. It's an extremely contrived example, but from the code I posted, it should just be: for x in xs: print(x) print(x) Much easier to read because there's only one way to write it. Hence GVR shunning map/reduce/filter.
- KirinDave 9y agoGVR is wrong. It's okay to be wrong. But the last 5 years of software development and the remarkable growth of Javascript as a platform accessible to everyone make a compelling case that GVR was wrong.
- empthought 9y agoNo it doesn't. It makes the case that the browser is the most pervasive and flexible application runtime, which we already knew. Server-side JavaScript was never a thing until that was solidified, thus providing a large developer base.
- KirinDave 9y agoWhy is this a meaningful distinction? Who cares if it's server or client side in this discussion? The Python community has said passing anonymous closures is too complex, the majority of the industry disagrees and has pushed forward. Lambdas are everywhere BUT Python now. Javascript is even pushing forward with more sophisticated constructs to help them build custom monadic constructs, and shipping a super useful monadic construct in syntax. C# has been doing that for years. Java will soon as well. The rest of the industry has moved on from this conceit and you can't really argue that it's made environments like Javascript overwhelming to newcomers. If Python 3 could just get over this conceit, its maintainers could start solving major Python problems really quickly. E.g., Python's janky iteration primitives could be replaced in an afternoon or three with equivalent but cleaner and clearer options.
- empthought 9y ago> Why is this a meaningful distinction? Who cares if it's server or client side in this discussion? It doesn't really matter, except that the browser's dominance as client-side platform is the cause of JavaScript's current ascendancy, rather than programming language design decisions of any sort. This is a refutation of the claim that you made saying "the last 5 years of software development and the remarkable growth of Javascript" make a compelling case that van Rossum is wrong about multiline anonymous functions in Python. Classic post hoc ergo propter hoc fallacy. If you're going to stick by the argument that somehow the support of anonymous functions is responsible for JavaScript's recent successes with respect to Python in terms of adoption and pace of development, then you'll have to explain why Lisp didn't take the world by storm when they were introduced nearly sixty years ago. Or, of course, admit that whether or not a particular programming language conforms to your personal preferences has relatively little bearing on the success of that programming language in the world at large.
- maxerickson 9y agoMaybe I misunderstand what you mean with "fully pre-computed", but local functions in Python close over local scope at runtime: >>> def splatter(t): ... def f(): print(t) ... return f ... >>> beep=splatter("beep") >>> boop=splatter("boop") >>> beep() beep >>> boop() boop That's the problem with Python, everything is dynamic.
- KirinDave 9y agoI meant structural precomputation. But yeah, I forget you can discard names. You're right: through sufficient use of discarded intermediate bindings you can replicate multi-line lambdas. Still, the existence of this sorta demands we ask, "So why can't we use it then?"
- maxerickson 9y agoI'm not steeped in functional programming, but isn't anonymity the least interesting part compared to being first class and forming closures?
- KingMob 9y agoI don't really see it as an FP thing at all, because the same argument can be made with respect to variable names. The issue is that without serious anonymous functions, you're forced to come up with more names, increasing cognitive load. An anonymous fn clearly communicates "I'm not going to be used elsewhere".
- xapata 9y agoSo call it something generic related to usage: keyfunc, repeat, parse, callback, etc.
- KirinDave 9y agoWhy increase the complexity and density of the code while complaining that the alternative would be too complex though? If I can simulate anonymous functions with locally scoped functions that then behave as lambdas then what hill is Python dying on here? The "we don't want to submit a patch to make our parser do this?" Hill? It's definitely possible to do. So...