Why not just `#define never (;0;)`? It even looks like an alien emoticon.

True, that's better, should have thought of it :)

Nah, I would love people to use Python -- just to help improve it as well (either through libraries, alternative languages or submitting changes through official channels.)

Saying I am "self aggrandising" is disingenuous and misleading at best.

> in this case JS absorbed the best pars of CS.

Actually my favorite part of CS is the instance var intitialization. e.g.:

    constructor(@x, @y) ->

would initialize @x and @y to the arguments. It makes writing records much nicer.

... Yeah, that's gnarly. :D That is emulating `let` using lambdas, though, and not mutable assignment. Still useful if you really want to nest them, but still immutable.

I don't know, isn't it possible to do the equivalent of mutable assignment if I use the same variable name several times?

For instance for the equivalent of x = 3; x = x + 1; print(x):

    (lambda x: (lambda x: print(x))(x+1))(3);

This is really cool. NamedDict is a useful thing indeed!

>Mobile support, you can't easily write a mobile application in Python.

Depends on your needs, but there is at least Kivy.

Same reason you're complaining in a comment instead of doing things.

He's complaining at you complaining :P

Huh, that's clever! (You meant `[]` though, yes?)

Yeah, I'll keep that in mind -- some people, even programmers, apparently don't like to read carefully. :)

>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_click(lambda: x += 1)

The language not supporting this (when most others do) is just silly.

> 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.

> 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.

>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.

But if you write a State equivalent of "x += 1" in Python then you can use it in a lambda too.

Are you saying that a non-mutating variant of the above works? For instance:

   foo.on_click(lambda:x func(x, whatever))

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.

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.

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.

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.

What is the proposed alternative? (using a named function or method just seems to be semantically the same, just more characters)

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.

    foo.on_click(partial(q.append, foo))

The nice thing about ``append`` is it's atomic (for builtins).

Where does the update of `x` go in this example? By observing a Queue or Stream `q`?

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.

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) ...

x += 1 should be a statement rather than an expression. It's not just a value, evaluating it has an effect.