4 ms·

I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. Not that this is necessarily a bad thing

I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. Not that this is necessarily a bad thing, per sé -- I think it does simplify the language. But it's an opinionated decision that will discourage FP enthusiasm from finding a home in Python. [1] http://lambda-the-ultimate.org/node/587 http://lambda-the-ultimate.org/node/587

mdrachuk 6y ago
BDFL made good points though.
uryga 6y ago
the Syntax section has a bit more: > "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this." so it's just keeping in line with Python's general imperativess. > FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé i, on the other hand, do think it's a bad thing :) but what can you do...
- adamnew123456 6y ago
  > i, on the other hand, do think it's a bad thing :) but what can you do... Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days. [1]: https://github.com/hylang/hy https://github.com/hylang/hy
pjmlp 6y ago
With a good mix of comprehensions, itertools, functools and lambda, there is enough stuff to get creative with FP in Python anyway.
- andybak 6y ago
  Yeah but constantly jumping between idioms means this is stuff I have to usually look up instead of just intuiting.
- uryga 6y ago
  btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions: let x = foo in expr can be [expr for x in (foo,)][0] (kinda reads like a Haskell `where` clause!) or: (lambda x = foo: expr)() useful in a pre-walrus-operator REPL :)
  - heavenlyblue 6y ago
    If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly? You would not get through code review with that in any shop that has discipline.
    - uryga 6y ago
      > You would not get through code review with that in any shop that has discipline. ... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production. PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp: [ y+y for x in my_list for y in (foo(x),) ] but it's (obviously) ugly & only useful if you're in a REPL and don't want to rewrite the whole thing.
dragonwriter 6y ago
> I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. That single comment from Guido 15 years ago, which was largely backtracked on—map and filter remain in the core library and reduce moved to a library in stdlib, lambda remains—is not really an example of something accurately described as “increasingly” now. In fact, given the backtracking, it's arguably decreasingly true from the high point of that post.
goto11 6y ago
Not sure about "increasingly" - note the comment you link to is 15 years old! It seems more like a recognition that map/filter/reduce never was idiomatic Python and there are better ways to do the same. Python have never tried to be a functional language.

mdrachuk 6y ago

BDFL made good points though.

uryga 6y ago

the Syntax section has a bit more: > "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this." so it's just keeping in line with Python's general imperativess. > FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé i, on the other hand, do think it's a bad thing :) but what can you do...

adamnew123456 6y ago
> i, on the other hand, do think it's a bad thing :) but what can you do... Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days. [1]: https://github.com/hylang/hy https://github.com/hylang/hy

pjmlp 6y ago

With a good mix of comprehensions, itertools, functools and lambda, there is enough stuff to get creative with FP in Python anyway.

andybak 6y ago
Yeah but constantly jumping between idioms means this is stuff I have to usually look up instead of just intuiting.
uryga 6y ago
btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions: let x = foo in expr can be [expr for x in (foo,)][0] (kinda reads like a Haskell `where` clause!) or: (lambda x = foo: expr)() useful in a pre-walrus-operator REPL :)
- heavenlyblue 6y ago
  If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly? You would not get through code review with that in any shop that has discipline.
  - uryga 6y ago
    > You would not get through code review with that in any shop that has discipline. ... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production. PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp: [ y+y for x in my_list for y in (foo(x),) ] but it's (obviously) ugly & only useful if you're in a REPL and don't want to rewrite the whole thing.

dragonwriter 6y ago

> I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. That single comment from Guido 15 years ago, which was largely backtracked on—map and filter remain in the core library and reduce moved to a library in stdlib, lambda remains—is not really an example of something accurately described as “increasingly” now. In fact, given the backtracking, it's arguably decreasingly true from the high point of that post.

goto11 6y ago

Not sure about "increasingly" - note the comment you link to is 15 years old! It seems more like a recognition that map/filter/reduce never was idiomatic Python and there are better ways to do the same. Python have never tried to be a functional language.