←back to thread

317 points est | 6 comments | | HN request time: 0s | source | bottom
Show context
amelius ◴[] No.17448876[source]
If they add anything to Python, it should be the ability to do functional-style programming without hassle. Right now it's almost impossible to compose functions in an inline style such as used in functional programming languages. Yes, there's lambda, but it doesn't extend into multiple lines, and applying a function to a bunch of lambdas directly leads to line-width overflow. Even JavaScript has better support for functional-style programming. Perhaps Guido should spend a year writing Haskell :)
replies(8): >>17448904 #>>17448927 #>>17448972 #>>17449048 #>>17449482 #>>17450517 #>>17450691 #>>17451251 #
1. i_do_not_agree ◴[] No.17448972[source]
Just need something like blocks in Smalltalk. Wikipedia page on list comprehensions says Smalltalk-80 had list comprehensions and that was ~ 40 years ago.

Smalltalk also uses ":=" for assignment and "=" for comparison. In Pharo, VA and Dolphin at least does what this Python proposal does - return the value of the last expression.

replies(3): >>17449086 #>>17449121 #>>17453671 #
2. yxhuvud ◴[] No.17449086[source]
Well, if you prefer blocks, you may as well use Ruby as that language is basically what happens when you have access to blocks.

Python chose a different design trajectory - personally I can't stand it but it certainly follow some sort of internally consistent reason.

replies(1): >>17449746 #
3. yxhuvud ◴[] No.17449121[source]
Ain't going to happen. Python used to have lambdas, but removed all but the one-line variety.

The problem is that if you add blocks, then half of the added syntactic features the last decade is redundant as a block version would simply solve the problem a better. Which would create a lot of dead design, and that makes it a bad solution.

replies(1): >>17450115 #
4. jrochkind1 ◴[] No.17449746[source]
There's a whole lot of smalltalk in ruby.
5. pseudalopex ◴[] No.17450115[source]
When did Python have multi-line lambdas?

Are you maybe conflating blocks with chained iterator operations? Adding blocks to Python's current functional syntax would be pretty ugly. "foo.filter(bar).map(baz)" is nice even if you can only use named functions.

6. dfox ◴[] No.17453671[source]
Smalltalk (and for that matter Ruby) has weird feature that blocks and methods are different different concepts.

In my opinion the Python's explicit self argument is somehow cleaner approach than having distinct block and function/method types. You still need some kind of ugliness in order to implement super(), but for Python 3 that happens at compile time and the resulting syntax is reasonably sane.

As for the aforementioned method context issue CLOS/MOP takes interesting approach of macroexpanding the method definition into something like

  (lambda (args next-method)
    (labels
      ((call-next-method &args)
        ...
        (funcall next-method ...)))
      (impl (...)
        ... method body ...))
     (funcall impl args)))
Also of note is that in ST, there are no control structures, even if is implemented as method on Boolean instances which takes block argument, with true and false being instances of True resp. False with different implementations of #ifTrue: method.