Hacker News Reader

Comment by lmm | Hacker News Reader

Python's semantics are unlikely to ever be fast and most Python users have already worked around its speed issues.

asyncio is new; python3 porting is happening. It seems unfair to complain that no real improvements are being made and also complain that these new things are immature.

reduce being pushed behind an import is stupid, but it's only one import.

lambda is fine, if you're writing in functional style you're using expressions for everything anyway. And you will probably be more persuasive if you can make your points less offensively.

For "bag of data" classes look at attrs.

(All that said, having found Scala I don't miss Python at all. (Except when writing a desktop GUI - PyQt was really nice))

View on HN

Here's a thoughtful critique of asyncio, posted some time ago on Hacker News: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...

Yes, attrs seems like a good solution for plain-old-data classes. https://attrs.readthedocs.io/en/stable/

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

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.

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

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

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.

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.

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.

Thank you for showing me attrs.

I love namedtuple, but this seems like a better implementation for light-weight classes.

Reply on news.ycombinator.com