Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Guido has a different, legitimate reason to not add multi-line lambdas to Python: they are super nasty to integrate with Python's grammar.

Python has a strict grammar where statements (which use indentation) contain expressions, but never vice versa. Allowing statement-body lambdas would give you an expression form that contains significant indentation that could be embedded in the middle of some larger expression, like:

    call(some(function(lambda:
      insideLambda()
      alsoInside()
    ))) # Ugh, where do these go?!
Handling that in a way that's readable and easy to parse is hard, and, I think, there's no solution that would fit naturally with Python's look and feel.

CoffeeScript does handle it, but I think it's one of the hairier corners of its grammar and the Python community isn't quite so gung ho about accommodating grammatical weirdness like that.



Python also has `yield` generator syntax which can approximate `async` syntax rather well (everything is still colored but less painful). There seems to be no concensus whether generators or promises ("futures") are better but it seems to be agreed that if you want nice syntax you should be happy with generators.

The worst problem is stdlib APIs weren't designed for any async style. => gevent's monkey-patching all of stdlib is considered among the _less_ nasty solutions :-(

On a deeper level, I don't think the Python community even agrees async is a very important problem. Unlike the self-selection Node enjoyed, many people work on software where mostly sync code is good enough.


Nim also handles it and it works pretty well I think.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: