Live data from Hacker News

Stop writing lambda expressions in Python

treyhunner.com

71–80 of 202 posts

Re: Stop writing lambda expressions in Python

#71
I generally like coding with lambdas, but in Python one thing I hate is that they will capture a numeric loop index by ref and not by its current value. If you try generating some polynomials x -> x, x^2, x^3 ... in the "obvious" way you'll see what I mean, all polynomials will be the same as the last one after the loop or list compr is done.

Theres a workaround using default arg value to capture by val but its ugly and easy to forget and hard to "see" in review that its missing.

This is as much an issue of loops not generating "fresh" instances of their index vars as it is a problem with lambdas, to be fair, but it still sucks, esp in mathematical domains. Julia used to suffer from this but fixed it, I believe the same is true for C# too.

Re: Stop writing lambda expressions in Python

#72

Personally, I use them often and disagree with a lot of this sentiment. I also disagree with a significant portion of PEP8, however. Anonymous functions are vital to any modern high level language. I think most people get hung up on the word. If the keyword was changed from “lambda” to “fun” for example I think it wouldn’t be as obtuse to more intermediate developers. To be honest I think the lambda does Python a ser…

> Anonymous functions are vital to any modern high level language.

I don’t think you’re wrong, but I am also not experienced enough to know why this would be the case. What is the virtue of having an anonymous function? I get that it makes code somewhat easier to read and write if you’re only using the function once and it’s short, but that seems like an edge case. What am I missing?

Re: Stop writing lambda expressions in Python

#73
post #4

all i could think of is "stop writing python". it seems to me that a lot of these problems are fundamental problems with python. i continue to not understand why anybody likes python the language. the fact that creating a function with lambda versus the normal way is different is bonkers. for example, in f# (and other sane languages), the following are identical: let test1 = fun x -> x * x let test2 x = x * x both re…

"i continue to not understand why anybody likes python the language."

As someone who has had a lifetime of on-off relationships with attempting to become a competent programmer, (BASIC, assembler, C, Pascal, Visual Basic, C++ and others that I can no longer remember), Python is the only language that has helped me become anywhere near useful or proficient as a programmer. I've managed to build a couple of -genuinely useful- applications (one of which is being used daily in my girlfriend's school), which hasn't been the case for anything else.

I've found that Python is simple enough to learn, and hasn't really been any kind of a limitation for me - this may be because of me, not the language - OK, I appreciate that I'm not going to be writing 3D games or real-time audio apps in it, but for what I've been trying to do (solve real-world problems), it's been amazing. I even programmed a 'play sound effects when you press a MIDI controller' system which I used at a show with 20,000 people attending this summer, replacing a massively over-complex (and expensive) audio environment with about 30 lines of Python combined with two libraries I spent an afternoon learning.

That, for me, is why I like Python.

Re: Stop writing lambda expressions in Python

#74
post #58

Earlier quoted context omitted.

It is, and that's the point. The Python community coined TOOWTDI (there's only one way to do it) in response to Perl's "There's more than one way to do it". What that way is seems to be "what even the most clueless programmer could reasonably understand". This to the point where even the adoption of a concept as common as assignment expressions was met with a community shitstorm. It seems like a language designed for…

To be honest, I feel like Python's philosophy makes it easier to focus on the "craft" of programming; instead of worrying about small details like how to iterate through a collection, I'm able to just do it the boring-but-effective Pythonic way and move on to higher-level details of the program. So I guess I'm not strictly disagreeing with you, but I think the craft of programming is about far more than just how your…

I suppose so, but the higher level details of a program will often follow from the nature of the language you are coding it in. I know a lot of my code would be "architected" differently if the language I was working in had a general disdain for passing anonymous functions around, and I don't think it would end up as effective.

And finding new more effective ways to do common things, new tricks so to speak, is important in keeping the mind engaged.

The tools might not be as important as the end product, but for the person who is always using those tools, being able to improve and customize them to their liking is extremely important.

I guess the difference is a programming language is less a tool than an end product in itself, that needs to be able to be understood and modified by other people. As opposed to say, a plumbers preferred toolset, of which no trace will be left when the next person comes to do the job.

Re: Stop writing lambda expressions in Python

#75

Python really needs much better anonymous functions - Lambda expressions just don't cut it. To be clear, what Python does need is multiline, inline anonymous functions. In JavaScript/ES2015, the fat arrow function syntax is just remarkably powerful in its ability to simplify code. I would go so far as to say that the ES2015 fat arrow syntax completely changed the way my programs are written, increasing power and redu…

Why does it need that, though? What's wrong with just naming the function?

Re: Stop writing lambda expressions in Python

#76

Python really needs much better anonymous functions - Lambda expressions just don't cut it. To be clear, what Python does need is multiline, inline anonymous functions. In JavaScript/ES2015, the fat arrow function syntax is just remarkably powerful in its ability to simplify code. I would go so far as to say that the ES2015 fat arrow syntax completely changed the way my programs are written, increasing power and redu…

Why does it need that, though? What's wrong with just naming the function?

There's real readability and clarity to positioning an anonymous function right at the point in the code that it will be used.

When you name and define a function some other place and use it elsewhere, you have increased the overall complexity. What is this named function? Where is it used? Is it accessed by other bits of code? Should it be? All these questions come up when you see a named function. It is in fact less readable and requires more code to define a named function elsewhere and then call it. Inline terse anonymous functions are more straightforward, self explanatory and simple.

It is often the case that you know an anonymous function will only ever be used once, in this particular bit of code so it is much more clean, readable and understandable if the anonymous function lives right there.

Especially valuable in reducing the complexity of async programming.

It's hard to make a strong case just in words, but once you really understand the power of the fat arrow syntax for anonymous inline functions then you use it more and more and it becomes second nature and the programs you write have a completely different style, oriented towards neatly positioned inline anonymous functions everywhere that typically can be read and understood at a glance as you skip through the code.

There is simply no other way to write a function that absolutely cannot be called by some other bit of code. That's the problem with functions that are defined outside their usage context - you may know for sure that the function will only ever be called from this one point in your code, but if you have to declare it as a named function elsewhere then there is always the possibility that in the future someone will come along and make use of that function - it is more complex in the immediate term and leaves open the door for increasingly code complexity in the longer term. Terse inline anonymous functions such as the fat arrow syntax solve this perfectly. They are so clear and easy to understand that it's actually rather beautiful.

This is how terse you can make a JavaScript fat arrow function:

  x => x
It is a function that take a param of x and returns x. A more useful example might be:

  message => console.log('new message: ', message)

My primary languages are Python and JavaScript .... and coming first and primarily from Python, I know that the Python community feels it has a monopoly on readability. But having gained a fair amount of experience in JavaScript too, I can now say that things like inline anonymous functions and the extremely terse fat arrow syntax greatly increase readability even further. If Python had both then it would be even more readable, terse and powerful. Add destructuring on top of that and programming in Python would be almost a new experience.

Re: Stop writing lambda expressions in Python

#77
post #71

I generally like coding with lambdas, but in Python one thing I hate is that they will capture a numeric loop index by ref and not by its current value. If you try generating some polynomials x -> x, x^2, x^3 ... in the "obvious" way you'll see what I mean, all polynomials will be the same as the last one after the loop or list compr is done. Theres a workaround using default arg value to capture by val but its ugly…

Yes! This caused one of the trickier bugs I've had (the functions were supposed to be almost the same anyway, but ended up identical). I thought of it immediately when reading this article.

Re: Stop writing lambda expressions in Python

#78
I've struggled with this balance for a while.

I've come down to the view that _defining a function using `def` syntax adds structure to a program_, even when it's not desired. It's multi-line, includes an indent and a keyword. It look more like creating a `Class` than a `list` for example.

As a result, in order to define a function _without_ adding structure people fall back on lambdas.

I think the best resolution would be to embolden lambdas with some of the benefits of functions - e.g. multiple lines

Re: Stop writing lambda expressions in Python

#79
post #68

Earlier quoted context omitted.

sure. here you go. http://www.gigamonkeys.com/code-quarterly/2011/hal-abelson/ the paragraph he says it in is: > It’s just a different course. We could have done it in Scheme and I sort of wish we had. And for random reasons we didn’t. But the thing that ties it together—if you had fifteen seconds to describe the whole course—it’s still about abstraction and modularity. The beginning of that course is not very differ…

Thanks for the link. The paragraph you quote makes me think he is comparing Python's lambda to Scheme's equivalent, which of course will make Python's lambda seem broken. IIRC the course was taught in Scheme at one time, but it switched to Python because it seemed easier for students to grasp the basics that way.

It's not just Scheme; in Common Lisp and Haskell and every other language that supports lambda, lambda is a first-class construct that is used all the time. Python's lambda feels like a war veteran that had its legs blown off. Best policy is probably just to pretend it's not in the language.

Re: Stop writing lambda expressions in Python

#80

Personally, I use them often and disagree with a lot of this sentiment. I also disagree with a significant portion of PEP8, however. Anonymous functions are vital to any modern high level language. I think most people get hung up on the word. If the keyword was changed from “lambda” to “fun” for example I think it wouldn’t be as obtuse to more intermediate developers. To be honest I think the lambda does Python a ser…

Van Rossum started to work on Python in 1989 and released the first version in 1991. Python is modern in the sense of being still very well alive but it's deeply rooted in the 80s, and it shows with all those double underscore __magic functions__, the self argument in methods (the way we were doing object oriented programming in C, without the ++) and others.

Compared to JavaScript it didn't evolve it's syntax much. Of course JS was much worse off to start with.

Post reply on HN