From: Brad Phelan <bradphelan@...>
Date: 2007-05-23T07:00:12+09:00
Subject: Re: How to adopt "Python Style" indentation for Ruby

Eric Mahurin wrote:
> On 5/22/07, Brad Phelan <bradphelan@xtargets.com> wrote:
>> I am not concerned really either way with the indentation thingie. I
>> don't think that is the main difference between python and Ruby. In my
>> op' the fact that Python does not do generic blocks is the main arguing
>> point. I am not sure why the indentation issue raises so much heat.
>>
>> What interests me about this thread is that, if you wish,
>> you can transparently add your own dialect to ruby by overloading
>> require. I've done the same thing before to load ERB files as if
>> they were real ruby files on the path. I jumped in at the challenge
>> of the OP as to whether transparent preprocessing is possible. The fact
>> that it is and so simply is a nice sign of the power of the ruby 
>> language.
> 
> Agreed.  Indentation vs. other ways of delimiting code blocks is just
> a surface issue.  For the most part, it is just a preference thing.
> 
> The lack of a real lambda (and its verbose syntax compared to ruby
> blocks) in python is a much bigger issue.  I still think python's
> crippling of the lambda has to do with the indentation thing.  The way
> they did it, indented code blocks ("suites") are only part of
> statements (not more generic expressions).  Since a lambda is an
> expression (probably used in an enclosing statment), it doesn't get to
> have generic code blocks.  With some rework, blocks delimited by
> indentation don't have to be so limited.
> 

Recently python allowed it's yield statement to be an expression
and return a value.

a =  ( yield b )

However I cannot see a useful way to use that from within python
as there is no intuiative way for the code block to return a value.
The only way to take advantage of it is the nonintuitve
coroutine syntax ala generator.send ( ... )

http://docs.python.org/whatsnew/pep-342.html

I don't see a fundamental reason that Python could not be extended
to have generic blocks ala Ruby but from reading some of the PEP's
it seems to be a deliberate design decision to avoid generic blocks.
The rationale as I have understood it is that generic blocks hide
looping constructs which should be explicit ( foreach ).

     http://www.python.org/dev/peps/pep-0343/
     """
     PEP 340, Anonymous Block Statements, combined many powerful ideas:
     using generators as block templates, adding exception handling and
     finalization to generators, and more.  Besides praise it received
     a lot of opposition from people who didn't like the fact that it
     was, under the covers, a (potential) looping construct.  This
     meant that break and continue in a block-statement would break or
     continue the block-statement, even if it was used as a non-looping
     resource management tool.
     """

Read the full PEP 343 to see the lengths that are gone to to implement
this. However I am curious to see some more knowledgeable Ruby people
explain how Ruby deals with the concerns raised by the Python guys. Some
of the issues are the usage of break and continue within blocks. Does
continue/break used from within a block continue/break the block or the 
most local for loop. I haven't tried myself to see what happens.

-- 
Brad Phelan
http://xtargets.com