5 ms·

Guido himself has said no multiline lambdas is an explicit design choice, and it's not really a technical issue: "But the complexity of any proposed solution f

Guido himself has said no multiline lambdas is an explicit design choice, and it's not really a technical issue: "But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption." source: http://www.artima.com/weblogs/viewpost.jsp?thread=147358 http://www.artima.com/weblogs/viewpost.jsp?thread=147358 EDIT: This was from an earlier proposal in 2006.

stdbrouw 12y ago
Doesn't make it any less annoying to not have them.
- munificent 12y ago
  Language design, especially syntax design, is always a series of trade-offs. Aside from relatively rare outright mistakes (bitwise precedence in C, associativity of ?: in PHP), most syntax choices that people don't like are done to make something else easier. I really like blocks, but Python deliberately makes it harder to support those in return for not needing scope delimiters in the majority of code that isn't using blocks. It seems like a reasonable choice to me.
  - BugBrother 12y ago
    Blocks could be allowed in one liners. That would make Python a credible solution in that use case. (And yes, not all one liners need it. I know.) And list comprehensions seems like a kludge from a lack of real lambdas (map). So that is an extra concept. Edit: Ruby doesn't have closures?! Edit 2: 2nd paragraph of the linked article: "In Ruby, Objective-C, and C, functions are not first-class objects, they don't capture closures, and they can't be defined inline." For Ruby, that don't claim there are no closures at all. Got it.
    - andrewvc 12y ago
      Ruby definitely does have closures.
    - actsasbuffoon 12y ago
      Methods aren't closures in Ruby (though we have procs and lambdas for that), but you certainly can pass methods around. Methods are objects, as are unbound methods. Both of them can be passed as arguments or returned as values. That's the definition of a first-class object. You don't see the pattern often, as it's far less idiomatic than passing procs as a block, but you can do it. Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.
      - mcphage 12y ago
        > Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created. They added that in 2.1 Well, it was always an expression... in Ruby, every statement is an expression. But it always used to return nil. Now it returns the symbol of the method name. Still not as good as returning a method object, but since you can easily get the method object from the symbol, in practice there's no difference.
  - dragonwriter 12y ago
    Honestly, if I had to choose between things I'd like to have in Python that exist in other languages, I'd choose improving the protocol supporting comprehension syntax improved to be more general (like Scala's) over blocks. While blocks are nice to have, I've yet to see a good proposed syntax for them in Python.
  - coldtea 12y ago
    >Language design, especially syntax design, is always a series of trade-offs. Sure, but then again not all trade-offs make the right trade, err, off.
    - munificent 12y ago
      Even saying "right trade-off" goes against what I'm trying to say. It may be the right trade-off for some users and the wrong trade-off for others. Most of the time, when people say, "this programming language is doing this thing wrong," all it really means is "this isn't the right language for me for this problem."
      - coldtea 12y ago
        That means any set of tradeoffs is valid. It's not. Tradeoffs are only OK if what you get back in each option is balanced. In some cases you're trading something very valuable for diminishing returns. >It may be the right trade-off for some users and the wrong trade-off for others. Well, then it matters how big are those groups relative to each other, and perhaps which one does something that's more important with the language and more tied to its core principles.
  - dreamweapon 12y ago
    associativity of ?: in PHP TIL that PHP is even scarier than I thought.
bryanlarsen 12y ago
The proposed solution in the original post doesn't require an indent-insensitive mode.
ceronman 12y ago
This is the only case where I think that using whitespace indentation for delimiting blocks of code is not a good idea. It makes this particular problem very difficult to solve elegantly. In languages where blocks are delimited by brackets is easer.
- angersock 12y ago
  ...perhaps this is a hint that significant whitespace is a bad idea?
  - lmm 12y ago
    It's an argument to weigh in the balance, yes. Given that Python is more readable than languages without significant whitespace (even when those languages have the advantage of easy multiline lambdas), I don't find it convincing.
  - pyre 12y ago
    ... like $[ in Perl?
    - draegtun 12y ago
      Fortunately $[ was disabled from v5.16.0 (released in 2012). ref: http://perldoc.perl.org/perl5160delta.html http://perldoc.perl.org/perl5160delta.html
bascule 12y ago
It definitely is a technical issue: Python simply doesn't support multiline expressions. Anything utilizing an indent block must be a statement by the nature of the Python grammar, and since lambdas pretty much require returning a value (the new lambda) to be useful (and are thus expressions), they cannot be modeled as statements in Python, and therefore can't utilize indent blocks. This is definitely an oddity of the Python grammar, where statements vs. expressions are entangled into how Python models indent blocks. Statements can contain expressions but expressions cannot contain statements. Compare to Haskell, an everything-is-an-expression language which still supports indent sensitivity and multiline lambdas. Guido just chose a wacky way to implement an indent-sensitive grammar.

stdbrouw 12y ago

Doesn't make it any less annoying to not have them.

munificent 12y ago
Language design, especially syntax design, is always a series of trade-offs. Aside from relatively rare outright mistakes (bitwise precedence in C, associativity of ?: in PHP), most syntax choices that people don't like are done to make something else easier. I really like blocks, but Python deliberately makes it harder to support those in return for not needing scope delimiters in the majority of code that isn't using blocks. It seems like a reasonable choice to me.
- BugBrother 12y ago
  Blocks could be allowed in one liners. That would make Python a credible solution in that use case. (And yes, not all one liners need it. I know.) And list comprehensions seems like a kludge from a lack of real lambdas (map). So that is an extra concept. Edit: Ruby doesn't have closures?! Edit 2: 2nd paragraph of the linked article: "In Ruby, Objective-C, and C, functions are not first-class objects, they don't capture closures, and they can't be defined inline." For Ruby, that don't claim there are no closures at all. Got it.
  - andrewvc 12y ago
    Ruby definitely does have closures.
  - actsasbuffoon 12y ago
    Methods aren't closures in Ruby (though we have procs and lambdas for that), but you certainly can pass methods around. Methods are objects, as are unbound methods. Both of them can be passed as arguments or returned as values. That's the definition of a first-class object. You don't see the pattern often, as it's far less idiomatic than passing procs as a block, but you can do it. Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.
    - mcphage 12y ago
      > Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created. They added that in 2.1 Well, it was always an expression... in Ruby, every statement is an expression. But it always used to return nil. Now it returns the symbol of the method name. Still not as good as returning a method object, but since you can easily get the method object from the symbol, in practice there's no difference.
- dragonwriter 12y ago
  Honestly, if I had to choose between things I'd like to have in Python that exist in other languages, I'd choose improving the protocol supporting comprehension syntax improved to be more general (like Scala's) over blocks. While blocks are nice to have, I've yet to see a good proposed syntax for them in Python.
- coldtea 12y ago
  >Language design, especially syntax design, is always a series of trade-offs. Sure, but then again not all trade-offs make the right trade, err, off.
  - munificent 12y ago
    Even saying "right trade-off" goes against what I'm trying to say. It may be the right trade-off for some users and the wrong trade-off for others. Most of the time, when people say, "this programming language is doing this thing wrong," all it really means is "this isn't the right language for me for this problem."
    - coldtea 12y ago
      That means any set of tradeoffs is valid. It's not. Tradeoffs are only OK if what you get back in each option is balanced. In some cases you're trading something very valuable for diminishing returns. >It may be the right trade-off for some users and the wrong trade-off for others. Well, then it matters how big are those groups relative to each other, and perhaps which one does something that's more important with the language and more tied to its core principles.
- dreamweapon 12y ago
  associativity of ?: in PHP TIL that PHP is even scarier than I thought.

bryanlarsen 12y ago

The proposed solution in the original post doesn't require an indent-insensitive mode.

ceronman 12y ago

This is the only case where I think that using whitespace indentation for delimiting blocks of code is not a good idea. It makes this particular problem very difficult to solve elegantly. In languages where blocks are delimited by brackets is easer.

angersock 12y ago
...perhaps this is a hint that significant whitespace is a bad idea?
- lmm 12y ago
  It's an argument to weigh in the balance, yes. Given that Python is more readable than languages without significant whitespace (even when those languages have the advantage of easy multiline lambdas), I don't find it convincing.
- pyre 12y ago
  ... like $[ in Perl?
  - draegtun 12y ago
    Fortunately $[ was disabled from v5.16.0 (released in 2012). ref: http://perldoc.perl.org/perl5160delta.html http://perldoc.perl.org/perl5160delta.html

bascule 12y ago

It definitely is a technical issue: Python simply doesn't support multiline expressions. Anything utilizing an indent block must be a statement by the nature of the Python grammar, and since lambdas pretty much require returning a value (the new lambda) to be useful (and are thus expressions), they cannot be modeled as statements in Python, and therefore can't utilize indent blocks. This is definitely an oddity of the Python grammar, where statements vs. expressions are entangled into how Python models indent blocks. Statements can contain expressions but expressions cannot contain statements. Compare to Haskell, an everything-is-an-expression language which still supports indent sensitivity and multiline lambdas. Guido just chose a wacky way to implement an indent-sensitive grammar.