Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Python Programming

docs.python.org

Post reply on HN
Print view View original

11–20 of 105 posts

Re: Functional Python Programming

#11

Post by FrustratedMonky »

vintagedave wrote: post #4

Thanks for posting this. Many years ago (2006?) I was a just-out-of-university programmer and a friend of a friend who wrote Python for Canonical sat me down and tried to teach me functional programming using Python. I was a poor learner: I didn't 'get it' (functional programming in general) and, to my regret, learned nothing. Much time has passed and I hope I'm a more aware and open-to-new-things person today :) I u…

I find that learning functional style in a language that does not enforce it, is extra difficult. If the language does not provide guard rails, then new learners will fall back on non-functional methods, and not even realize it.

Re: Functional Python Programming

#12

Post by Mizza »

I thought I knew functional programming from knowing Python, but looking back I didn't really "grok" it until I moved to Elixir. Now I like it and prefer it. I don't run into any of the types of bugs I used to create in Python, mostly from being lazy and fiddling with data inside of a loop. I miss do miss early returns though.

Re: Functional Python Programming

#13

Post by agumonkey »

FrustratedMonky wrote: post #7
agumonkey wrote: post #5

Earlier quoted context omitted.

functional I can't say, but match was highly related to structural typing which was very much central in FP/LP culture

Think this is answer. It isn't technically needed to be called 'functional', but it is so integral to type systems that it seems to be used in all functional languages. Maybe we can call 'match' statements an emergent phenomena of functional languages.

and i'm sure the idea floated around in non FP languages too, but

1) mutable programming shifts the idioms very very far away from passive destructuring, they like to deref pointers and reuse memory cells

2) it's also linked to parametric type systems I believe, which was missing until cpp/java5 in the mainstream (while FP had this since milner which was in the 70s)

Re: Functional Python Programming

#14

Post by _dain_ »

stayfrosty420 wrote: post #9

@dataclass is the new final

Does the type system let you express that a class shouldn't be subclassed? I remember this possibility was mentioned in a PEP and got deferred. It would be really useful with the new match/case pattern matching feature, because then you could have proper sum types, and mypy could enforce exhaustiveness. AFAIK you have to do a workaround with a "assert False" or similar at the end.

Re: Functional Python Programming

#15

Post by qbasic_forever »

vintagedave wrote: post #4

Thanks for posting this. Many years ago (2006?) I was a just-out-of-university programmer and a friend of a friend who wrote Python for Canonical sat me down and tried to teach me functional programming using Python. I was a poor learner: I didn't 'get it' (functional programming in general) and, to my regret, learned nothing. Much time has passed and I hope I'm a more aware and open-to-new-things person today :) I u…

IMHO broaden your boundaries a bit and learn a lisp or clojure-based functional style, like grab a getting started in clojure book and work through it. You will learn a lot more than this guide goes into, it's really just looking at functions in a functional style but doesn't spend nearly enough on data structures and state which are really the core of functional programming (and what python doesn't do well out of the box for functional programming).

Learning a bit of clojure will really open your eyes to what functional programming means, and you can take some of those learnings back to python.

Re: Functional Python Programming

#16

Post by linkdd »

raphaelj wrote: post #8

Sadly, Python is a pretty poor functional language. The core of functional programming is about avoiding mutable states , not much about anonymous functions or passing functions as data. To do proper functional programming in Python, there should be IMO: - a way to enforce non-mutable variables/objects; - non-mutable collections; - proper support for recursion and tail-recursion optimization; - a better syntax for an…

For tail recursion, you can use this snippet of code:

  class Recurse(Exception):
      def __init__(self, *args, **kwargs):
          self.args = args
          self.kwargs = kwargs
  
  class Terminate(Exception):
      def __init__(self, retval):
          self.retval = retval

  def tailrec(func):
      def wrapper(*args, **kwargs):
          while True:
              try:
                  func(*args, **kwargs)

              except Recurse as r:
                  args = r.args
                  kwargs = r.kwargs

              except Terminate as t:
                  return t.retval

      return wrapper

  @tailrec
  def fact(n, acc=1):
      if n == 0:
          raise Terminate(acc)

      else:
          raise Recurse(n - 1, acc * n)
Of course, it will be slow because it relies on exceptions :P

Re: Functional Python Programming

#19

Post by nerdponx »

_dain_ wrote: post #14
stayfrosty420 wrote: post #9

@dataclass is the new final

Does the type system let you express that a class shouldn't be subclassed? I remember this possibility was mentioned in a PEP and got deferred. It would be really useful with the new match/case pattern matching feature, because then you could have proper sum types, and mypy could enforce exhaustiveness. AFAIK you have to do a workaround with a "assert False" or similar at the end.

Yes, that's what @typing.final is: https://docs.python.org/3/library/typing.html#typing.final

But that's only checked by the type checker. At runtime you still need to do something like this to prevent subclassing:

  class DontSubclassMe:
      def __init_subclass__(self):
          raise TypeError("Don't subclass me!")

Re: Functional Python Programming

#20

Post by amanj41 »

qbasic_forever wrote: post #10
raphaelj wrote: post #8

Sadly, Python is a pretty poor functional language. The core of functional programming is about avoiding mutable states , not much about anonymous functions or passing functions as data. To do proper functional programming in Python, there should be IMO: - a way to enforce non-mutable variables/objects; - non-mutable collections; - proper support for recursion and tail-recursion optimization; - a better syntax for an…

I agree but it's not so dire, the tuple type (and variants like namedtuple) is pretty powerful, non-mutable and often my first choice for data structure in python. Everything else can be built on top of it if you're really motivated.

I would add frozenset as the other immutable collection. The other points are well taken though
Post reply on HN