Well, if you prefer blocks, you may as well use Ruby as that language is basically what happens when you have access to blocks.

Python chose a different design trajectory - personally I can't stand it but it certainly follow some sort of internally consistent reason.

There's a whole lot of smalltalk in ruby.

Smalltalk (and for that matter Ruby) has weird feature that blocks and methods are different different concepts.

In my opinion the Python's explicit self argument is somehow cleaner approach than having distinct block and function/method types. You still need some kind of ugliness in order to implement super(), but for Python 3 that happens at compile time and the resulting syntax is reasonably sane.

As for the aforementioned method context issue CLOS/MOP takes interesting approach of macroexpanding the method definition into something like

  (lambda (args next-method)
    (labels
      ((call-next-method &args)
        ...
        (funcall next-method ...)))
      (impl (...)
        ... method body ...))
     (funcall impl args)))

Also of note is that in ST, there are no control structures, even if is implemented as method on Boolean instances which takes block argument, with true and false being instances of True resp. False with different implementations of #ifTrue: method.

Ain't going to happen. Python used to have lambdas, but removed all but the one-line variety.

The problem is that if you add blocks, then half of the added syntactic features the last decade is redundant as a block version would simply solve the problem a better. Which would create a lot of dead design, and that makes it a bad solution.

When did Python have multi-line lambdas?

Are you maybe conflating blocks with chained iterator operations? Adding blocks to Python's current functional syntax would be pretty ugly. "foo.filter(bar).map(baz)" is nice even if you can only use named functions.