From: Bill Kelly <billk@...>
Date: 2009-05-21T14:29:44+09:00
Subject: Re: Pythonic indentation (or: beating a dead horse)


From: "Tony Arcieri" <tony@medioh.com>
>
> I'll refer to Guido van Rossum on this one:
>
>> The unspoken, right brain http://en.wikipedia.org/wiki/Right_brain
>> constraint here is that the complexity introduced by a solution to a design
>> problem must be somehow proportional to the problem's importance. In my
>> mind, the inability of lambda to contain a print statement or a while-loop
>> etc. is only a minor flaw; after all instead of a lambda you can just use a
>> named function nested in the current scope.

I think this helps illustrate the degree of subjectivity
involved in how varying people regard this issue.

For me, I've written sufficient Python code in years past
to have concluded that significant indentation adds too
much rigidity to the language for it to feel like an
acceptable trade-off for what it accomplishes.
(The mere existence of the 'pass' keyword is slightly
eye-rolling to me.... presumably similar to how others
may feel about a raft of closing 'end' statments.)

My preferences are opposite to Guido's, above.  A flexible
lambda, for instance, is *far* more important to me than
what I consider to be a minor nuisance of nested 'end'
statements.  (And non-nested 'end' statements don't bother
me at all.  Some percentage of extra scrolling in the
editor isn't of any relative importance to me.)

As far as nested 'end' statements, one thing I've been
trying lately is to define the module hierarchy at the top
of the file, then qualify the class name so that nesting
is avoided.  Like,

module CILA end
module CILA::SVC end

class CILA::SVC::Hub

  # ........ methods here as usual ........

end

class CILA::SVC::HubClientConn

  # ........ methods here as usual ........

end

So far I'm pretty happy with this approach.


Regards,

Bill