[Python-Dev] PEP 340 - possible new name for block-statement

[Phillip J. Eby]

At 12:05 PM 4/29/05 -0700, Aahz wrote:
>On Fri, Apr 29, 2005, Phillip J. Eby wrote:
> > At 10:42 AM 4/29/05 -0700, Aahz wrote:
> >>On Fri, Apr 29, 2005, Guido van Rossum wrote:
> >>> [Phillip J. Eby]
> >>>>
> >>>> Although I'd personally prefer a no-keyword approach:
> >>>>
> >>>>      synchronized(self):
> >>>>          with_file("foo") as f:
> >>>>              # etc.
> >>>
> >>> I'd like that too, but it was shot down at least once. Maybe we can
> >>> resurrect it?
> >>>
> >>>     opening("foo") as f:
> >>>         # etc.
> >>
> >>I'm still -1 for the same reason I mentioned earlier: function calls
> >>spanning multiple lines are moderately common in Python code, and it's
> >>hard to distinguish these cases because multi-line calls usually get
> >>indented like blocks.
> >
> > But the indentation of a multi-line call doesn't start with a colon.
>
>Neither does the un-keyworded block.  It starts with a colon on the end
>of the previous line.  I thought part of the point of Python was to
>minimize reliance on punctuation, especially where it's not clearly
>visible?

Actually, I've just realized that I was misled by your argument into 
thinking that the possibility of confusing a multi-line call and a block of 
this sort is a problem.  It's not, because template blocks can be viewed as 
multi-line calls that just happen to include a block of code as one of the 
arguments.   So, mistaking one for the other when you're just skimming the 
code and not looking at things like "as" or the ":", is really not important.

In the second place, the most important cue to understanding the behavior 
of a template block is the template function itself; the bare syntax gives 
it the most prominence.  Blocks like 'synchronized(self):' should be 
instantly comprehensible to Java programmers, for example, and 'retry(3):' 
is also pretty self-explanatory.  And so far, template function names and 
signatures have been quite brief as well.