Isn't a comprehension just a map/filter by another syntax? You can re-create them from a list comprehension pretty simply:

`map = lambda data, map_fn : [map_fn(x) for x in data]`

`filter = lambda data, filter_fn : [x for x in data if filter_fn(x)]`

Then, why even have the lambda-translations above since the comprehension is already "Pythonic"? Also, you have functools (https://docs.python.org/3/library/functools.html) which you can use for several functional programming paradigms as well.

Functional programming isn't what you call the techniques (map/filter/etc.) it's how you are programming that makes it functional. You can still use functional techniques in Python to make things a bit easier to reason about. A lot of the things people thing about functional programming aren't inherent to the actual functional programming paradigm: like laziness or immutability.

Python is fine with maps and filters, and has lazy calculations.

You can also have a look at "generator expressions", which are the lazy counterpart to a list comprehension (hint: use " ()" instead of "[]").

https://docs.python.org/3/library/functions.html#map

https://docs.python.org/3/library/functions.html#filter

https://docs.python.org/3/howto/functional.html

   x = [i*2 for i in range(5)] #[0, 2, 4, 6, 8]
   y = [i for i in range(8) if i%2 == 0] #[0, 2, 4, 6, 8]
   z = [[1],[2],[3],[4]]
   w = [j for i in z for j in i] #[1,2,3,4]
   t = {str(j):j*2 for j in w} #{"1":1, "2":4, "3":6, "4":8}
   
   #reduce (note the generator (i for i in range(20))... that's a lazy list essentially)
   reduce(lambda acc, x: x + acc, (i for i in range(20)), 0) #sum(0 ... 20)
   
   
   #get max value from a bunch of numbers:
   f = max(i for i in range(30) if 30 % 3 == 0) #max(0, 3, 9, 12, 15, 18, 21, 24, 27, 30) = 30
   
   #basic recursion
   def myreverse(x: str) -> str:
       return x if len(x) <= 1 else x[-1] + myreverse(x[:-1]) #O(N) on each slice, (However x[-1] is O(1) unlike the haskell list). 

   #qsort haskell style
   def qsort(l: List[int]) -> List[int]:
       return l if len(l) <= 1 else qsort([i for i in l if i <= l[0]]) + qsort([i for i in l if i > l[0]]) 

Additionally lambda syntax, aka python anonymous first class functions HAVE to be functional.

   f = lambda x: x + 1

The type hints that python uses are also quite good with support for generics sum types and even type level programming (however your type checker needs to support it too and basically none of them do right now) You can literally assign a type to a variable in python. See: https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html

I would say the main weakness in python is that the IMPLEMENTATION is not well suited for functional programming (but the syntax VERY much is). Tail slices on lists like x[1:] cost O(N) and that's the biggest issue right now imo. It makes some valid solutions on leetcode exceed the time limit because it adds and additional N complexity on every slice when the head and tail functions in haskell cost O(1)

I'm sure some library can easily provide the underlying functional primitives python needs to be faster. Actually on that note, does anyone know of a library that solves the head tail slicing problem I described above? Probably should use the python deque, but the api for that is inherently not functional.

Just a small note that the walrus operator gives you some wiggle room here:

  add_5_to_square_if_greater_than_10 = lambda x: squared + 5 if (squared := x * x) > 10 else x
  assert add_5_to_square_if_greater_than_10(2) == 2
  assert add_5_to_square_if_greater_than_10(5) == 30

They have to be a single python expression, but that’s not the same as the usual understanding of “functional” (i.e., referentially transparent). Consider:

  d = {"foo": 1}
  f = lambda m: d.update({k, v+d.get(k,0) for k,v in m.items()}) or d

Python lists are not lisp-style lists, which is more efficient for most uses, but not for a lot of functional-style algorithms which leverage cheap head/tail splits.

But it wouldn't be hard to write a typed sequence class that wrapped a lisp-style immutable list implemented with nested tuples with the deepest nested one an empty tuple in Python, there's just not a lot of demand for it.

True, yeah

>But it wouldn't be hard to write a typed sequence class that wrapped a lisp-style immutable list implemented with nested tuples with the deepest nested one an empty tuple in Python, there's just not a lot of demand for it.

A doubly linked list with the same slice syntax would be fine. You can use java style classes as it's just the underlying implementation. There's no demand (currently) but it's a good idea as python syntax works extremely well (better then even javascript) for functional programming.