Blocks in other languages can help maintain encapsulation, if they can access variables from their local scope. They can also enable programmers to write their own control structures which look like natural first class control structures in the host language. I don't see this as a natural way of doing either.

    def sorted_by(xs, attr):
        def cmp_attr(a, b):
            return cmp(getattr(a, attr), getattr(b, attr))
        return sorted(xs, cmp_attr)

    var load_into = function (url, elem) {
        var handle_response = function (response) {
            $(elem).html(response);
        };

        $.get(url, handle_response);
    };

I agree that this doesn't fit Python well, but why was it bad in Ruby?

Anonymous functions can generally be abused in ways that make code harder to read. Then again, so can recursion. It's a double edged sword.

Some people may consider:

    def is_prime(n):
        if n % 2 == 0:
            return False

        sqrt_n = int(math.floor(math.sqrt(n)))
        for i in range(3, sqrt_n + 1, 2):
            if n % i == 0:
                return False
        return True

    def main():
        with concurrent.futures.ProcessPoolExecutor() as executor:
            for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
                print('%d is prime: %s' % (number, prime))

uglier than (borrowing some JavaScript syntax):

    def main():
        with concurrent.futures.ProcessPoolExecutor() as executor:
            for number, prime in zip(PRIMES, executor.map(
                    function(n) {
                        if n % 2 == 0:
                            return False

                        sqrt_n = int(math.floor(math.sqrt(n)))
                        for i in range(3, sqrt_n + 1, 2):
                            if n % i == 0:
                                return False
                        return True
                    }
                    , PRIMES)):

                print('%d is prime: %s' % (number, prime))

I don't, mostly because in the second example, I cannot unit test the anon version of is_prime in isolation. This is a rather trivial case, but I've seen much more complex and enigmatic anon functions in Node applications.

Note: the original comes from http://docs.python.org/dev/library/concurrent.futures.html#p...

I'm not sure there is one. They're useful in C# as a way of defining a function within another function (which sometimes makes for more readable code). For example:

    public int CountRelevantItems(IEnumerable<Thing> things)
    {
      // Non-trivial filter that you don't want in a where lamdba
      Func<Thing, bool> isRelevant = (t) =>
      {
        ...
      }
      
      return things.Where(t => isRelevant(t)).Count()
    }

But in Python you can already define functions inside of functions so you have a better solution:

    def CountRelevantThings(things):
      def isRelevant(thing):
        ...
      return len(filter(isRelevant, things))

If the code block can run in a different thread (like in Grand Central Dispatch) it is very useful to do stuff in the background without blocking the GUI (that executes in a specific thread) and using the current scope variables. A progress bar is a clear example of this.

Doing this without code blocks adds extra code like launching another thread, connecting the scope to the new thread.

I think that "readability" also depends on what you're used to reading and writing. To me, my code blocks are quite readable, but that's only true because I've seen a lot of them in these last two weeks.

Code blocks let you write

  with myfunc(iter) << 'x, y':
    code which uses x and y

instead of

  def some_func_name(x, y):
    code which uses x and y
  myfunc(iter, some_func_name)

If you prefer the second form, then you don't need code blocks. I think the first form is much better. It's not just a matter of saving one single line: you don't have to define a function which you'll never use again, so the first code is actually more readable.

    "Here is what my DSL can look like with Blocks in Smalltalk"
    (condition)
        ifTrue: [ ... ]
        ifFalse: [ ... ]
        ifMaybe: [ ... ]

You can accomplish the same thing with named functions and function pointers, but it makes the DSL very awkward to use. Imagine if you had to write all of your conditional logic (if-then and if-then-else and switch) using the names of functions defined elsewhere. That would be much less readable than being able to write block of code inline.

The problem with that is that it forces moving the code above where it is passed, which can greatly clutter things.

For example, consider the function "forever" in Haskell:

  forever action = do
    action
    forever action

Now you can use it as a new control structure, e.g:

  forever $ do
    (sock, addr) <- accept listener
    forkIO $ handleClient sock

The $ simply means "apply" and is low-precedence, so it removes the need to put () around the entire argument to be applied.

In Python, you could define:

  def forever(action):
    action()
    forever(action)

but then, to use it, you have to give a name to your function, so:

  def accept_once():
    (sock, addr) = listener.accept()
    fork(partial(handleClient, sock))
  forever(accept_once)

This makes "forever" much less useful as a new control structure/looping primitive.

In this sense, Python makes DSLs less usable. The built-in primitives are first-class, and can have code directly within their use. Library functions are second-class, and can only have code passed by name which must then fully appear before the use.

Another example is callbacks. The reason "twisted" is probably called "twisted", and that people hate callbacks so much, is that it forces writing the code in backwards order, precisely because of this problem. For example:

  def handle_result(result):
    print "Done:", result
  def connection_started(conn):
    conn.request(SomeRequest(), handle_result)
  def start():
    start_connecting(connection_started)

Compare this with Haskell, as an example:

  start = startConnecting $ \conn -> do
    request conn SomeRequest $ \result -> do
      putStrLn $ "Done: " ++ show result

Note, in Haskell, this would actually be worked out to be (by overloading the semicolon):

  start = do
    conn <- startConnecting
    result <- request conn SomeRequest
    putStrLn $ "Done: " ++ show result

But even the former nested representation is better than the backwards ("twisted") representation that makes people hate callbacks so much.

  >>> def fight(batman_wins):
  ...     def t(): return "pow"
  ...     def f(): return "oof"
  ...     def b(msg): print msg
  ...     # if_but not defined at this point
  ...     if_but(lambda: batman_wins, t, f, b)
  ...
  >>> def if_but(cond, true, false, but):
  ...     if cond():
  ...       v = true()
  ...     else:
  ...       v = false()
  ...     but(v)
  ...
  >>> fight(True)
  pow
  >>> fight(False)
  oof

    while True:
      action()

  replicateM 10 . forkIO . forever $ do
    ..

  replicateM 10 (forkIO (forever (do ..)))

    myTransaction 
        commit: [
            "Stuff happens here"
        ]
        onRollback: [   
            "handles rollback"
        ].

    (mySemaphore)
        critical: [
            "critical section code goes here"
        ].

It looks like you changed "lambda" to "def" and added parentheses. It seems like that feature is already there...

Do you mean 'nonlocal' keyword?

Not the whole story. Code blocks can be used to protect encapsulation and create DSLs which are first class citizens of their host language.

So your named functions, functions, lambdas, code blocks, etc, become.. well.. equivalent.

They can also become so lexically awkward as to be unusable. For example, one code a toy "fuzzy logic" system in Smalltalk with a handful of methods. The result looks like a 1st class member of the language, just like the control structures that are already there. (Same goes for the loops)

    "Here is the standard if-else"
    (condition)
        ifTrue: [ ... ]
        ifFalse: [ ... ]

    "Here is what my DSL can look like"
    (condition)
        ifTrue: [ ... ]
        ifFalse: [ ... ]
        ifMaybe: [ ... ]

Doing this with named functions is going to scatter code between different functions. It's semantically equivalent, but harder to read. Write anything involved in such a way, and it becomes untenable. Blocks can make such DSLs an order of magnitude more readable.

Hipsters, don't confuse the young ones with your 30 ways of jumping into a block of code. Cheers!

A good heaping fraction of hipsters don't understand what's good about code blocks.

Just read the docstring of the module. It's very detailed.

As for mixing strings with code, I still need to adhere to Python's syntax in order to avoid syntax errors. Anyway, syntax errors in strings are caught at "rewriting time". Using words instead of operators would also cause some problems.

By the way, I wish that '<' was a simple typo. Unfortunately it's Wordpress: it's driving me mad. Everytime some code has '<' and '>' in it, something unexpected happens.

No. You can always use "named blocks", but they are called functions.

Oh, I know. My module is your fault! :)