I think this is a good one; I hope people agree. Its acceptance will
obsolete about 4 other PEPs! (A sign that it fulfills a need and that
the proposed solution is powerful.)

What about making the ':' optional (and end implicitly at end of current
block) to avoid over-indentation?

def foo():
     with locking(someMutex)
     with opening(readFilename) as input
     with opening(writeFilename) as output
     ...

would be equivalent to:

def foo():
     with locking(someMutex)
         with opening(readFilename) as input
             with opening(writeFilename) as output
                 ...

Regards,

Your approach wouldn't allow the following

with locking(mutex):
  increment_counter()

x = counter()

with locking(mutex):
  decrement_counter()

except by making a new block, as

if 1:
  locking(mutex)

  x = counter()

if 1:
  locking(mutex)

If the number of blocks is a problem it wouldn't be that
hard to do

with multi( locking(someMutex),
            opening(readFilename),
            opening(writeFilename) ) as _, input, output:
  ...

Untested sketch of an implementation

class multi(object):
  def __init__(self, *args):
    self.args = args
  def __enter__(self):
    results = []
    for i, arg in enumerate(self.args):
      try:
        results.append(arg.__enter__())
      except:
        # back up through the already __entered__ args
        exc = sys.exc_info()
        for j in range(i-1, -1, -1):
          try:
            self.args[j].__exit__(*exc)
          except:
            # Need to get the new exception, to match the PEP behavior
            exc = sys.exc_info()
        raise exc[0], exc[1], exc[2]
    return results

  def __exit__(self, type, value, traceback):
    for arg in self.args[::-1]:
      try:
        arg.__exit__(type, value, traceback)
      except:
        type, value, traceback = sys.exc_info()

But yes, it creates a precedent by creating a statement affecting the
end of the current indentation block.  But that's what this PEP is all
about...

with locking(mutex), opening(readfile) as input:
    ...

So there could be more than one expression in one with.

Anyway, I like the idea of the PEP too.

What I meant to say was in the PEP

     with locking(someMutex)
         with opening(readFilename) as input
             with opening(writeFilename) as output
                 ...

it's very well defined when the __exit__() methods are
called and in which order.  If it's

     with locking(someMutex)
     with opening(readFilename) as input
     with opening(writeFilename) as output

with the __exit__()s called at the end of the scope (as if it
were a __del__, which it isn't) then the implementation could
still get the __exit__ order correct, by being careful.  Though
there would be no way to catch an exception raised in an __exit__.
I think.

with abc:
  with cde:
    pass

and

with abc
with def

and to have the second form act somewhat like RAII in that
the __exit__() for that case is called when the scope ends.

Hmm.  My first thought is I don't like it because I'm a stodgy
old traditionalist and don't like the ambiguity of having to look
multiple tokens ahead to figure out which form is which.  

I can see that it would work.  Umm, though it's tricky.  Consider

with abc

with defg:
  with ghi
  with jkl:
    1/0

The implementation would need to track all the with/as forms
in a block so they can be __exit__()ed as appropriate.  In this
case ghi.__exit() is called after jkl.__exit__() and
before defg.__exit__

The PEP gives an easy-to-understand mapping from the proposed
change to how it could be implemented by hand in the existing
Python.  Can you do the same?

with EXPR as x:
      BLOCK

EXPR can be a tuple so the above would be ambiguous.

Note that if I wrote:

with locking(mutex):
     with opening(readfile) as input:
         ...

it's clear that input is the return value of
opening(readfile).__enter__(), and that the mutex is held while the file
is opened.  I don't need to memorize these things; they are explicit in
the syntax.

I can see making the with-statement proposal more complex if you had
some very good motivating examples for wanting the multiple-expressions
extension.  But you have yet to provide a real-world use case.  Go
search your codebase, and find some examples of where you would actually
use this.  For the complexity that you want to add to the
with-statement, you need to show that there's a *large* advantage to a
*variety* of use cases in *real-world* code.

 > with abc
 >
 > with defg:
 >   with ghi
 >   with jkl:
 >     1/0

is equivalent to:

 > with abc:
 >
 >   with defg:
 >     with ghi:
 >       with jkl:
 >         1/0

That's it.  Nothing more complex.  It's only about syntax.

But there's another point that has nothing to do with how many "with"
statements you have in a function.  In C++, very very rarely I've seen
something like:

void foo() {
     {  // (define a scope for the Lock object)
        Lock locking(myMutex);
        ...
     }
     ...
     {
        Lock locking(myMutex);
        ...
     }

So basically, there's two 10-90% points, one in favor of my proposal,
one against:

- Most of the time, you don't have a lot of with-statements in a single
function, so not so much indentation.
- Most of the time, a with-statement ends at the end of current block,
so indentation-syntax most of the time result in a waste of space.

The way to see my proposal is not "to be used when you have multiple
with-blocks" but instead "never use the ':' syntax, unless necessary".
The day some code need it, it's very easy to add a ':' and indent some
code with our favorite editor.

Consider the following

server = open_server_connection()
with abc(server)
with server.lock()
do_something(server)

server.close()

it would be translated to

server = open_server_connection()
with abc(server):
  with server.lock()
    do_something(server)
    server.close()

when I meant for the first code example to be implemented
like this

server = open_server_connection()
with abc(server):
  with server.lock()
    do_something(server)

server.close()

(It should probably use the with-block to handle the server open
and close, but that's due to my lack of imagination in coming up
with a decent example.)

Because of the implicit indentation it isn't easy to see that
the "server.close()" is in an inner block and not at the outer
one that it appears to be in.  To understand the true scoping
a reader would need to scan the code for 'with' lines, rather
than just looking at the layout.

That's not to say it's a good indicator.  A lot of existing code
looks like this

def get_first_line(filename):
  f = open(filename)
  return f.readline()

depending on the gc to clean up the code.  A more ... not
correct, but at least finicky ... implementation could be

def get_first_line(filename):
  f = open(filename)
  try:
    return f.readline()
  finally:
    f.close()

Almost no one does that.  With the PEP perhaps the idiomatic
code would be

def get_first_line(filename):
  with open(filename) as f:
    return f.readline()

(Add __enter__/__exit__ semantics to the file object?  Make
a new 'opening' function?  Don't know.)

What I mean by all of this is that the new PEP may encourage
more people to use indented blocks, in a way that can't be
inferred by simply looking at existing code.  In that case
your proposal, or the one written

  with abc, defg(mutex) as D, server.lock() as L:
    ..

may be needed.

     with locking(mutex) as lock, opening(readfile) as input:
         ...

There was another proposal that wrote this as:

     with locking(mutex), opening(readfile) as lock, input:
         ...

which is what was confusing me.  Mirroring the 'as' from the import
statement seems reasonable.

But it doesn't address my other concern, namely, is

     with locking(mutex), opening(readfile) as input:
         ...

equivalent to the nested with-statements, e.g.:

     _locking = locking(mutex)
     _exc1 = (None, None, None)
     _locking.__enter__()
     try:
         try:
             _opening = opening(readfile)
             _exc2 = (None, None, None)
             input = _opening.__enter__()
             try:
                 try:
                     ...
                 except:
                     _exc2 = sys.exc_info()
                     raise
             finally:
                 _opening.__exit__(*exc)
         except:
             _exc1 = sys.exc_info()
             raise
     finally:
         _locking.__exit__(*exc)

Or is it equivalent to something different, perhaps:

     _locking = locking(mutex)
     _opening = opening(readfile)
     _exc = (None, None, None)
     _locking.__enter__()
     input = _opening.__enter__()
     try:
         try:
             ...
         except:
             _exc = sys.exc_info()
             raise
     finally:
         _opening.__exit__(*exc)
         _locking.__exit__(*exc)

Or maybe:

     _locking = locking(mutex)
     _opening = opening(readfile)
     _exc = (None, None, None)
     _locking.__enter__()
     input = _opening.__enter__()
     try:
         try:
             ...
         except:
             _exc = sys.exc_info()
             raise
     finally:
         # same order as __enter__ calls this time!!
         _locking.__exit__(*exc)
         _opening.__exit__(*exc)

All I'm saying is that any of these are possible given the syntax.  And
I don't see a precedent in Python for preferring one over another.
(Though perhaps there is one somewhere that I'm missing...)

And if it *is* just equivalent to the nested with-statements, how often
will this actually be useful?  Is it a common occurrence to need
multiple with-statements?  Is the benefit of saving a level of
indentation going to outweigh the complexity added by complicating the
with-statement?

with locking(mutex):
  with opening(readfile) as input:
    ...

which appears to map to the first of your alternatives

with server.opening() as connection, connection.lock(column) as C:
  C.replace("X", "Y")

The inner with depends on the outer and must be closed
in inverted order.

def getFirstLine(filename):
     with opening(filename) as file
     return file.readline()

than:

def getFirstLine(filename):
     with opening(filename) as file:
         return file.readline()

But I agree that in the case of only one with-statement, that's no big deal.

Also, if multiple with-statements are separated by other indentating
statements, your proposal doesn't help:

with locking(lock)
if condition:
     with opening(filename) as file
     for line in file:
         ...

would still be needed to be written:

with locking(lock):
     if condition:
         with opening(filename) as file:
             for line in file:
                 ...

It's however less obvious at first look that with-statements implies
some scope, but I feel that Python newcomers usually do the opposite
error instead, thinking their variables have a defined scope as in some
other languages.

     with EXPR as VAR:
         BLOCK

is equivalent to:

     abc = EXPR
     exc = (None, None, None)
     VAR = abc.__enter__()
     try:
         try:
             BLOCK
         except:
             exc = sys.exc_info()
             raise
     finally:
         abc.__exit__(*exc)

Can you do the same thing for your proposal?  As I understand it you
want some sort of implicitly-defined BLOCK that starts the line after
the with statement and runs to the end of the current block...

Do you think the benefit of less indentation outweighs the added
complexity of explaining the construct?  I still can't think of a good
way of explaining the semantics you want.  If you could provide an
explanation that's simple and as explicit as Guido's explanation in PEP
343, I think that would help your case a lot.

STeVe

"""
To avoid over-indentation, a with-statement can avoid defining a new
indentation block.  In that case, the end of the with block is the end
of the current indentation block.

with EXPR as VAR
REST OF BLOCK

is equivalent to

with EXPR as VAR:
     BLOCK
"""

What do you think?  I fail to see the complexity...

All these changes can also be made later, so no proposition should slow
down the implementation of the PEP.

def func(arg, baz):
     foo = bar(arg)
     with x as foo(baz)
     x.frobble()
     with y as x.bop()
     return frabble(x, y)

with:

def func(arg, baz):
     foo = bar(arg)
     with x as foo(baz):
         x.frobble()
         with y as x.bop():
             return frabble(x, y)

I find it much easier to identify in the second one that __exit__()
methods will be called right before the function returns (after the
return statement).  YMMV.

BTW, if you really like the optional-indentation idea, you should post
it to the Wiki page (http://wiki.python.org/moin/WithStatement) --
Guido's been pretty quick to respond to any comments made there, so you
could get some feedback much more useful than I can give you. ;)