6 ms·

I wholeheartedly agree that all languages should be judged on the quality of their libraries and implementation, as well as the success of the projects implemen

by showell 17y ago

I wholeheartedly agree that all languages should be judged on the quality of their libraries and implementation, as well as the success of the projects implemented on top of them. Ruby and Python have a pretty good track record there. One of the themes of Gary's talk was that Ruby is more expressive/flexible than Python, and lisp was thrown into the discussion as sort of a "gold standard" of expressiveness/flexibility, without necessarily passing any judgment on overall merits of the three languages. To the extent that Ruby strives for more flexibility, it is probably way more influenced by Perl than lisp. As somebody who has used both Ruby and Python fairly extensively, I think Ruby is undeniably more expressive than Python at times, but also more arcane at others. Some of the differences probably come from irreconcilable tradeoffs, where you cannot have your cake and eat it too, but other tradeoffs are probably less necessary, which is why people continue to discuss it. In the case of Ruby, it's a pretty young language, so there are probably opportunities to make it more appealing to a Python mindset without losing its great flexibility, although I do not have specific proposals. The conference Gary spoke at was a Python conference, so most people were more interested in ways that Python could learn from Ruby, without sacrificing Pythonicness. Gary seemed to reach the conclusion that the number one feature he envied in Ruby was blocks. Speaking for myself, I wish Python just had some kind of anonymous function syntax that was more rich than lambdas, even if it were not exactly semantically similar to Ruby blocks.

Deestan 17y ago
> I wish Python just had some kind of anonymous function syntax that was more rich than lambdas A lot of people keep saying this, including the article author, and I'm having trouble understanding why. Lambdas are for "one-liners", functions are for more-liners. Any time you want to write multiple lines in a lambda it's trivial to make it a named function. def listSomeTable(name): print name.center(40, "=") def getWeirdNumberPair(cap): while True: a = random.randint(1, cap) b = random.randint(1, cap) if (a==1) and (b==1): continue return (a, b) for i in xrange(20): print getWeirdNumberPair(i) print "="*40 What do you want to use multiline-lambdas for that you can't do (equally simply and elegantly) with named functions?
- grandalf 17y ago
  You are correct. There is no reason not to just use an inline function that happens to have a name. I think the "lambdas can only be one line" is a newbie python mistake.
  - steveklabnik 17y ago
    Personally, I dislike naming things that I won't use again. It feels like a waste. And then, since I have to name things, I have to come up with a _good_ name. Just a matter of taste, mind you, but it's my reasoning for preferring anonymous functions.
    - grandalf 17y ago
      They do make code more readable sometimes... but I think they are often used in Ruby as an alternative to @obj.method(:foo) -- in other words the Rubyist would use lambda{@obj.foo} and the pythonista would use obj.foo
- eru 17y ago
  Yes, Python's functions are meant to be named.
- silentbicycle 17y ago
  The real problem with lambdas in Python isn't that they're restricted to one expression, but that Python's implementation of closures is clumsy (due to a scoping ambiguity). The argument about whether lambdas should be named or not is a canard. In languages that make heavy use of lexically scoped functions defined on the fly (Scheme, ML, etc.), they're often given local names. The problem is that Python's locally defined functions are less expressive. Apparently making heavy use of closures is not "pythonic".
- mjw 17y ago
  Giving people concise syntax for passing anonymous functions allows one to implement a lot of control-flow operations, and combinators from functional programming, as libraries, rather than language constructs. In python, although they could technically be done as libraries, from a syntactic point of view, having to declare named functions and pass them explicitly as arguments rather defeats the elegance of the approach. So instead we have special features and syntax added to the language, like with statements and list comprehensions, which are limited special cases of what can be expressed more generally with a nice syntax for passing closures as arguments. Not that it necessarily matters, there's always a pythonic way to do the equivalent thing. Although a lot of the time it's more imperative, and my taste is for functional programming idioms where possible.

by showell 17y ago

Deestan 17y ago

> I wish Python just had some kind of anonymous function syntax that was more rich than lambdas A lot of people keep saying this, including the article author, and I'm having trouble understanding why. Lambdas are for "one-liners", functions are for more-liners. Any time you want to write multiple lines in a lambda it's trivial to make it a named function. def listSomeTable(name): print name.center(40, "=") def getWeirdNumberPair(cap): while True: a = random.randint(1, cap) b = random.randint(1, cap) if (a==1) and (b==1): continue return (a, b) for i in xrange(20): print getWeirdNumberPair(i) print "="*40 What do you want to use multiline-lambdas for that you can't do (equally simply and elegantly) with named functions?

grandalf 17y ago
You are correct. There is no reason not to just use an inline function that happens to have a name. I think the "lambdas can only be one line" is a newbie python mistake.
- steveklabnik 17y ago
  Personally, I dislike naming things that I won't use again. It feels like a waste. And then, since I have to name things, I have to come up with a _good_ name. Just a matter of taste, mind you, but it's my reasoning for preferring anonymous functions.
  - grandalf 17y ago
    They do make code more readable sometimes... but I think they are often used in Ruby as an alternative to @obj.method(:foo) -- in other words the Rubyist would use lambda{@obj.foo} and the pythonista would use obj.foo
eru 17y ago
Yes, Python's functions are meant to be named.
silentbicycle 17y ago
The real problem with lambdas in Python isn't that they're restricted to one expression, but that Python's implementation of closures is clumsy (due to a scoping ambiguity). The argument about whether lambdas should be named or not is a canard. In languages that make heavy use of lexically scoped functions defined on the fly (Scheme, ML, etc.), they're often given local names. The problem is that Python's locally defined functions are less expressive. Apparently making heavy use of closures is not "pythonic".
mjw 17y ago
Giving people concise syntax for passing anonymous functions allows one to implement a lot of control-flow operations, and combinators from functional programming, as libraries, rather than language constructs. In python, although they could technically be done as libraries, from a syntactic point of view, having to declare named functions and pass them explicitly as arguments rather defeats the elegance of the approach. So instead we have special features and syntax added to the language, like with statements and list comprehensions, which are limited special cases of what can be expressed more generally with a nice syntax for passing closures as arguments. Not that it necessarily matters, there's always a pythonic way to do the equivalent thing. Although a lot of the time it's more imperative, and my taste is for functional programming idioms where possible.