Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop writing lambda expressions in Python

treyhunner.com

Post reply on HN
Print view View original

141–150 of 202 posts

Re: Stop writing lambda expressions in Python

#141

Post by pseudalopex »

FridgeSeal wrote: post #123
nikofeyn wrote: post #16

Earlier quoted context omitted.

in my experience, the python ecosystem is a mess. yes, there are lots of libraries, but that is just one part of the ecosystem. for one, everyone uses a different distribution, whether it's anaconda, python(x,y), or just the default python install. this creates a lot of fragmentation, and it's hard to come into a project and fix the mess that's been created. then there's the 2.x vs 3.x issue that is still a problem.…

You're right, it is a mess. Don't get me wrong, there's a huge number of packages available and a lot of them are really quality and I have used the language a lot , but good gosh is the packaging a deployment a fucking disaster. Environments are a 3rd party bolt on, that relies on hacking around with environment variables. There's no distinction between dev dependencies and actual, application dependencies. The pack…

Python packaging has a lot of warts, but you can specify dev dependencies in extras_require. Also, you can just run a virtual environment's interpreter without "activating" the environment.

Re: Stop writing lambda expressions in Python

#142

Post by steveklabnik »

kbumsik wrote: post #134
FridgeSeal wrote: post #119

Earlier quoted context omitted.

Guido seemingly has a strong distaste for functional ideas, so anything that comes from that paradigm ends up getting an almost half-assed implementation. See also: map and filter being the only 2 other functions implemented and both of them being less performant than their imperative equivalents; outright denial of any attempt at TCO because "Guido doesn't like recursion".

> outright denial of any attempt at TCO because "Guido doesn't like recursion". No, don’t ignore problems of TCO by saying “guys don’t like functional programimg”. Guido cleary states why he doesn’t like it: [1]. Even though TCO is one of the ES6 standard, TCO also is largely denied by JS implementors (Firefox, Chrome, and Edge devs) because of the similar reasons. As a result, Safari is the only browser that support…

It’s not that we’re not eager, it’s that it’s harder in a systems language and historically there’s been limitations in LLVM.

We will sometimes optimize for TCO, that issue is that we can’t guarantee it just yet.

Re: Stop writing lambda expressions in Python

#143

Post by steveklabnik »

ChrisSD wrote: post #89
pmontra wrote: post #80

Earlier quoted context omitted.

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.…

`self` is about being explicit with parameters. Rust does the same thing and that's a more "modern" language. The `__magic__` is about avoiding naming conflicts while still being explicit. It's a choice between magic or reserving a lot of names.

Rust also has the issue of having three kinds of self, and those differences matter.

Re: Stop writing lambda expressions in Python

#144

Post by mlthoughts2018 »

zmmmmm wrote: post #128
another-cuppa wrote: post #75

Earlier quoted context omitted.

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

It's not so much naming the function, but that doing so moves it outside the flow of the logic it is participating in. Especially when it's going to reference local context that is particularly confusing. There are definitely times when extracting out a function and naming it is the right thing to do. But there are an equal number of times when keeping all the local context together is better. It's probably hard to a…

I find it tremendously helpful to move the function out of the flow of logic so it is modularized. When I read scala or haskell code where as soon as you see map or filter or something you know you’re gonna get some crazy anonymous function to follow, I get sad because it’s a miserable and confusing way to write code instead of pulling the function out into a separate definition with documentation, and then having the map or filter part be extremely concise using only predefined functions.

Re: Stop writing lambda expressions in Python

#145

Post by mlthoughts2018 »

andrewstuart wrote: post #76
another-cuppa wrote: post #75

Earlier quoted context omitted.

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 les…

I actually think that positioning an anonymous function at the site where it’s used is extremely unreadable and unintuitive. I work in Scala and Haskell a lot so I see it all the time and I’m usually forced to write code that way to stick to local conventions, and I despise it.

It makes no sense at all to break up the wonderful conceptual flow of functional components like map, fmap, filters, folds, monadic operations, with sudden harsh definition of a function that takes your brain out of the context of what was flowing and into the context of what is the function.

I want to see something like

    val someStat = myData.groupBy(thingExtractor)
      .foldLeft(baselineValue)(statAccumulator)
I want the mental task of grokking thingExtractor, baselineValue or statAccumulator to be a wholly separate task from seeing what flows into the calculation of someStat. I want to look elsewhere in the code for those things, kind of like expanding or collapsing a block of text: keep it out of mind when it doesn’t matter.

Re: Stop writing lambda expressions in Python

#146

Post by andrewstuart »

joshuamorton wrote: post #133
andrewstuart wrote: post #131

Earlier quoted context omitted.

Hmmmm. I don't see the relationship between async/await and fat arrows. Can you explain more about how async/await obviates the need for fat arrows?

Just async is callback based. You don't need callbacks with async/await. No callbacks, no need for fat arrow.

Interesting idea.

Re: Stop writing lambda expressions in Python

#147

Post by eesmith »

a-nikolaev wrote: post #109
eesmith wrote: post #106

Earlier quoted context omitted.

It also doesn't have tail-recursion or macros. There are many who also regard that lack as a deep design flaw. There never was a goal in Python development to support all programming paradigms. How do you distinguish between "design flaw" and "different design goal than what you want"?

I think, it was an example of intentional hostile design (say, see this video https://www.youtube.com/watch?v=NWZLB8CyPbM for what I mean). All, seemingly for the sake of that "only-one-way-to-do-things" goal. EDIT: (Van Rossum's own explanation of why he thinks lambda's design is okay: https://www.artima.com/weblogs/viewpost.jsp?thread=147358 )

Do you have any evidence for your hypothesis about hostile design?

The phrase, by the way, is "one obvious way".

Re: Stop writing lambda expressions in Python

#148

Post by another-cuppa »

zmmmmm wrote: post #128
another-cuppa wrote: post #75

Earlier quoted context omitted.

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

It's not so much naming the function, but that doing so moves it outside the flow of the logic it is participating in. Especially when it's going to reference local context that is particularly confusing. There are definitely times when extracting out a function and naming it is the right thing to do. But there are an equal number of times when keeping all the local context together is better. It's probably hard to a…

I've used Lisp extensively and I've used closures extensively. In Python you can simply define the function on the line above where you plan to use it. I really don't see the need. Lisp needs lambda because you can't just randomly introduce new variables everywhere (you have to use flet, which actually is a lambda).

Re: Stop writing lambda expressions in Python

#149

Post by another-cuppa »

andrewstuart wrote: post #76
another-cuppa wrote: post #75

Earlier quoted context omitted.

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 les…

You do realise you can define a function inside another function in python, right?

Re: Stop writing lambda expressions in Python

#150

Post by another-cuppa »

andrewstuart wrote: post #87
y7 wrote: post #85

Earlier quoted context omitted.

Python has a convention for "private" functions, which is to prepend "_" to the name. > 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 everyw…

Private functions do not restrict the usage of that function to one point in the code. There's a world of difference between a coding convention - essentially a comment to say "please don't access this function from outside the current class" versus it simply being impossible to do so. And the "private" convention does not say "don't use this function at any other point except one", it says "please don't access this…

Come on. You've defined a function inside another function. It's very clear that you've done it so you can pass it to some higher level function. If someone comes along and starts using your inner function willy nilly in the outer function without anyone noticing then you've got much bigger problems that multiline lambdas are not going to help you with.
Post reply on HN