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.