6 ms·

>lambda is fine, if you're writing in functional style you're using expressions for everything anyway. No, I /really would/ like to be able to write: foo.on_c

• mundanevoice 10y ago
  Try using some other language that is functional like LISP or Haskell maybe. Python goals is not be a functional language that that's okay.
• lmm 10y ago
  That seems like an exceedingly error-prone thing to write. "x +=1" isn't a value and the unmanaged mutation will be surprising when it happens. On a Python implementation with parallelism (e.g. Jython) you could very easily end up losing updates - on CPython the GIL will probably mean your code accidentally doesn't exhibit that problem, but that doesn't seem a very desirable way to code.
  • jononor 10y ago
    What is the proposed alternative? (using a named function or method just seems to be semantically the same, just more characters)
    • lmm 10y ago
      Something like functional reactive programming style, where you explicitly define a pipeline from foo.click to x and explicitly gather together all your pipelines (explicitly defining the interleaving semantics rather than just "whenever an event happens it happens") and run them in one place.
    • xapata 10y ago
      foo.on_click(partial(q.append, foo)) The nice thing about ``append`` is it's atomic (for builtins).
      • jononor 10y ago
        Where does the update of `x` go in this example? By observing a Queue or Stream `q`?
        • xapata 10y ago
          If it must be mutable state, then ideally you'd have a single consumer thread for counting off that queue to avoid worrying about locks. Or maybe what's in the queue gets written to a permanent log and ``x`` is a query of that log, a la Datomic.
        • deleted 10y ago
          [deleted]
• amyjess 10y ago
  > foo.on_click(lambda: x += 1) Mutation in lambdas is not compatible with your complaint about "inadequate support for high-level functional programming", as it goes against the principles of FP. You can't do that in Haskell either, and any FP purist would blanch at a statement like that.
  • darkf 10y ago
    >You can't do that in Haskell either, and any FP purist would blanch at a statement like that. Obviously you've never met State and/or lens then. Yes, you can do it -- and no, I never said it should follow pure FP principles.
    • lmm 10y ago
      But if you write a State equivalent of "x += 1" in Python then you can use it in a lambda too.
  • codygman 10y ago
    > You can't do that in Haskell either, and any FP purist What about us FP pragmatists? Also in some domains I'd argue being a FP purist is the most pragmatic option.
  • kazinator 10y ago
    Are you saying that a non-mutating variant of the above works? For instance: foo.on_click(lambda:x func(x, whatever))
    • dragonwriter 10y ago
      yeah, except that the syntax is lambda x: func(x, whatever) In fact, if x is an object that stores a mutable numeric cell, you could even do a mutating: lambda x: x.add(1) Mutation isn't prohibited in Python lambdas, statements (including assignments, which are statements rather than expressions in Python), however, are.
• mst 10y ago
  Huh. In perl (and javascript) x += 1 is an expression that returns the new value of x. I guess this is another "simplification" along with the magic scoping model (I want perl's my/ES6's let damnit sulk) ...
  • lmm 10y ago
    x += 1 should be a statement rather than an expression. It's not just a value, evaluating it has an effect.
• BeetleB 10y ago
  It is amusing your lambda usage could be used by the Python community as a classic example of problems that can occur if they allowed what you want. Mutating variables in a lambda is something abhorred in many functional languages.
• BuuQu9hu 10y ago
  I understand that you want to salvage Python, but it's time to look around and smell the roses. It's okay that we have non-Python languages. Some of them are pretty cool. For example, in Monte: foo.onClick(fn { x += 1 }) Totally legal, because there are no statements; it's an expression language.