https://docs.python.org/3/library/operator.html
In particular 'attrgettr' and 'itemgettr' are very useful functions to map over objects and sequences.
21–30 of 202 posts
https://docs.python.org/3/library/operator.html
In particular 'attrgettr' and 'itemgettr' are very useful functions to map over objects and sequences.
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…
In F#, can you ask a function object what its original name was? If so, what is the original name of "test1" and "test2" in your example? That's what python is doing and why the two are different. (I don't think a language should track that sort of thing, but that's a different story).
val test1 : x:int -> int
val test2 : x:int -> int
you call them the same way, and they have the same type. a caller has no knowledge of how they were defined because it isn't important. they're identical.The argument used by the author for 'abs' and 'min' can also be useful for all of the functions in the operator module: https://docs.python.org/3/library/operator.html In particular 'attrgettr' and 'itemgettr' are very useful functions to map over objects and sequences.
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…
Here are some reasons why I like it:
It's cleaner to read because there aren't curly braces and semicolons cluttering up the code.
It's cleaner to write because the expressions are simpler and look like something readable instead of line noise.
It has a REPL, so it's easy to experiment.
It doesn't force me to write boilerplate code, such as types for every variable declaration or everything having to be a class or huge amounts of scaffolding just to write "Hello, world!".
I'm sure I could think of more, but those are what come to mind on the spur of the moment.
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…
Can you give a link? I'd be interested to read it.
Earlier quoted context omitted.
I disagree... I came for the syntax and readability; I've stayed for the community.
I suppose I like the readability too, but there are a number of things about the language I would rather had been done differently; I still insist that its approach to scope is worse than any choice except making everything global.
> I’d say that using lambda expressions is acceptable only if your situation meets all four of these criteria: > 1. The operation you’re doing is trivial: the function doesn’t deserve a name Sure. > 2. Having a lambda expression makes your code more understandable than the function names you can think of This is just vague. Locally defining a function right where you need it makes code much more understandable to me…
This only might be valid if people on the team weren't programmers, but rather researchers that had to use python. In that case, the code would have to be very easy to understand. But in that case, they should probably learn what a lambda function is. It's really not that hard
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…
Amen, brother. I'm not proficient in Python, but from my (admittedly, limited) experience with it, it feels like programming with a straightjacket on.
It seems like a language designed for people who really have no interest in craft of programming, and just use it as a means to an end (note I'm not saying there's anything wrong with this, but if your career is in programming, and you keep that attitude, I'd suggest you find another one or move to management, you're not gonna be happy).
So in Python, imperative style is often more idiomatic than code that uses lambda expressions. While in some functional languages (Haskell) and array programming languages (J), tacit or point-free style is often more idiomatic than lambda expressions (or equivalent). There's something funny about that.
1. It is usually taken too far (indeed I think flip is probably too far and (.).(.) is certainly too far. I’m also not a big fan of eg fmap.fmap)
2. (.) is the wrong way round. Code reads much better if it has type (a -> b) -> (b -> c) -> (a -> c)
In APL or J was I don’t have enough experience to say other than that I find it difficult to read but the puzzle is amusing