For review: PEP 343: Anonymous Block Redux and Generator Enhancements

Discussion in 'Python' started by Guido van Rossum, Jun 3, 2005.

  1. After many rounds of discussion on python-dev, I'm inviting public
    comments for PEP 343. Rather than posting the entire PEP text here,
    I'm inviting everyone to read it on line
    (http://www.python.org/peps/pep-0343.html) and then post comments on a
    Wiki page I've created for this purpose
    (http://wiki.python.org/moin/WithStatement).

    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.)

    --
    --Guido van Rossum (home page: http://www.python.org/~guido/)
    Guido van Rossum, Jun 3, 2005
    #1
    1. Advertising

  2. Guido van Rossum wrote:
    > After many rounds of discussion on python-dev, I'm inviting public
    > comments for PEP 343. Rather than posting the entire PEP text here,
    > I'm inviting everyone to read it on line
    > (http://www.python.org/peps/pep-0343.html) and then post comments on a
    > Wiki page I've created for this purpose
    > (http://wiki.python.org/moin/WithStatement).
    >
    > 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.)


    I like the PEP very much; I guess most C++ programmers are missing that
    capability in Python. (I was following the discussion on python-dev,
    and I'm pleased and surprised how good the result/compromise is).

    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,

    Nicolas
    Nicolas Fleury, Jun 3, 2005
    #2
    1. Advertising

  3. Guido van Rossum

    Andrew Dalke Guest

    Nicolas Fleury wrote:
    > 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
    > ...


    Nothing in Python ends at the end of the current block.
    They only end with the scope exits. The order of deletion
    is not defined, and you would change that as well.

    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()

    Andrew
    Andrew Dalke, Jun 3, 2005
    #3
  4. Andrew Dalke wrote:
    >>def foo():
    >> with locking(someMutex)
    >> with opening(readFilename) as input
    >> with opening(writeFilename) as output
    >> ...

    >
    >
    > Nothing in Python ends at the end of the current block.
    > They only end with the scope exits. The order of deletion
    > is not defined, and you would change that as well.


    There's no change in order of deletion, it's just about defining the
    order of calls to __exit__, and they are exactly the same. As far as I
    know, PEP343 has nothing to do with order of deletion, which is still
    implementation-dependant. It's not a constructor/destructor thing like
    in C++ RAII, but __enter__/__exit__.

    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...

    > Your approach wouldn't allow the following


    No, I said making the ':' *optional*. I totally agree supporting ':' is
    useful.

    > 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:
    > ...


    True. But does it look as good? Particularly the _ part?

    Regards,
    Nicolas
    Nicolas Fleury, Jun 3, 2005
    #4
  5. Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

    Nicolas Fleury <_remove_the_> writes:

    > 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
    > ...


    How about this instead:

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

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

    > would be equivalent to:
    >
    > def foo():
    > with locking(someMutex)
    > with opening(readFilename) as input
    > with opening(writeFilename) as output
    > ...


    The thing is that with normal try-finally block, you can add more
    things to it easily. This kind of with thing does not allow adding
    more stuff to it in any other way than adding more indentation.

    Anyway, I like the idea of the PEP too.

    --
    Ilpo Nyyssönen # biny # /* :) */
    Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=, Jun 4, 2005
    #5
  6. Guido van Rossum

    Andrew Dalke Guest

    Nicolas Fleury wrote:
    > There's no change in order of deletion, it's just about defining the
    > order of calls to __exit__, and they are exactly the same.


    BTW, my own understanding of this is proposal is still slight.
    I realize a bit better that I'm not explaining myself correctly.

    > As far as I
    > know, PEP343 has nothing to do with order of deletion, which is still
    > implementation-dependant. It's not a constructor/destructor thing like
    > in C++ RAII, but __enter__/__exit__.


    I'm mixing (because of my lack of full comprehension) RAII with
    your proposal.

    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.

    >> Your approach wouldn't allow the following

    >
    > No, I said making the ':' *optional*. I totally agree supporting ':' is
    > useful.


    Ahh, I think I understand. You want both

    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?

    > True. But does it look as good? Particularly the _ part?


    I have not idea if the problem you propose (multiple with/as
    blocks) will even exist so I can't comment on which solution
    looks good. It may not be a problem in real code, so not needing
    any solution.

    Andrew
    Andrew Dalke, Jun 4, 2005
    #6
  7. Guido van Rossum

    Robin Becker Guest

    Re: For review: PEP 343: Anonymous Block Redux and Generator Enhancements

    Ilpo Nyyssönen wrote:
    ........
    >
    > with locking(mutex), opening(readfile) as input:
    > ...

    .....

    with EXPR as x:
    BLOCK

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

    --
    Robin Becker
    Robin Becker, Jun 4, 2005
    #7
  8. Guido van Rossum

    Kent Johnson Guest

    Re: For review: PEP 343: Anonymous Block Redux and Generator Enhancements

    Robin Becker wrote:
    > Ilpo Nyyssönen wrote:
    >>
    >> with locking(mutex), opening(readfile) as input:
    >> ...

    >
    > with EXPR as x:
    > BLOCK
    >
    > EXPR can be a tuple so the above would be ambiguous.


    I don't think EXPR can be a tuple; the result of evaluating EXPR must have __enter__() and __exit__() methods. *x* can be a tuple.

    Kent
    Kent Johnson, Jun 4, 2005
    #8
  9. Guido van Rossum

    Robin Becker Guest

    Re: For review: PEP 343: Anonymous Block Redux and Generator Enhancements

    Kent Johnson wrote:
    > Robin Becker wrote:
    >
    >> Ilpo Nyyssönen wrote:
    >>
    >>>
    >>> with locking(mutex), opening(readfile) as input:
    >>> ...

    >>
    >>
    >> with EXPR as x:
    >> BLOCK
    >>
    >> EXPR can be a tuple so the above would be ambiguous.

    >
    >
    > I don't think EXPR can be a tuple; the result of evaluating EXPR must
    > have __enter__() and __exit__() methods. *x* can be a tuple.
    >
    > Kent


    Well perhaps this would fly then. I reread the PEP and it says EXPR is
    arbitrary, but cannot be an expression list so maybe this was already
    considered and rejected.
    --
    Robin Becker
    Robin Becker, Jun 4, 2005
    #9
  10. Guido van Rossum

    Guest

    Ilpo Nyyssönen wrote:
    > Nicolas Fleury <_remove_the_> writes:
    > > def foo():
    > > with locking(someMutex)
    > > with opening(readFilename) as input
    > > with opening(writeFilename) as output
    > > ...

    >
    > How about this instead:
    >
    > with locking(mutex), opening(readfile) as input:
    > ...


    +1, and add PEP-328-like parentheses for multiline.

    Oren
    , Jun 4, 2005
    #10
  11. Ilpo Nyyssönen wrote:
    > How about this instead:
    >
    > with locking(mutex), opening(readfile) as input:
    > ...
    >


    I don't like the ambiguity this proposal introduces. What is input
    bound to? The return value of locking(mutex).__enter__() or the return
    value of opening(readfile).__enter__()? Seems ambiguous to me. And is
    the file opened with the mutex held, or not? Sure, all of these
    questions can be answered with an arbitrary decision. But the point is
    that, whatever decision you make, I now have to *memorize* that decision.

    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.

    STeVe
    Steven Bethard, Jun 4, 2005
    #11
  12. Andrew Dalke wrote:
    > 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?


    I think it is simple and that the implementation is as much
    straight-forward. Think about it, it just means that:

    > 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.

    > I have not idea if the problem you propose (multiple with/as
    > blocks) will even exist so I can't comment on which solution
    > looks good. It may not be a problem in real code, so not needing
    > any solution.


    Good point. As a C++ programmer, I use RAII a lot. However, there's
    situations in C++ that don't apply, like allocating dynamic memory in a
    scope. However, I still expect some Python programmers to use it enough
    to ask for that syntax to be added, in the same way operators like +=
    have been added.

    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 I come to another conclusion: the indentation syntax will most of the
    time result in a waste of space. Typically a programmer would want its
    with-block to end at the end of the current block.

    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.

    Regards,
    Nicolas
    Nicolas Fleury, Jun 4, 2005
    #12
  13. Guido van Rossum

    Andrew Dalke Guest

    On Sat, 04 Jun 2005 10:43:48 -0600, Steven Bethard wrote:
    > Ilpo Nyyssönen wrote:
    >> How about this instead:
    >>
    >> with locking(mutex), opening(readfile) as input:
    >> ...


    > I don't like the ambiguity this proposal introduces. What is input
    > bound to?


    It would use the same logic as the import statement, which already
    supports an 'as' like this

    >>> import sys, math, cStringIO as StringIO, xml.sax.saxutils as su
    >>>


    > But the point is
    > that, whatever decision you make, I now have to *memorize* that decision.


    It's the same rule so the rule would be "ahh, uses the 'as' form".

    Andrew
    Andrew Dalke, Jun 4, 2005
    #13
  14. Guido van Rossum

    Andrew Dalke Guest

    Nicolas Fleury wrote:
    > I think it is simple and that the implementation is as much
    > straight-forward. Think about it, it just means that:


    Okay, I think I understand now.

    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.


    > Good point. As a C++ programmer, I use RAII a lot.


    And I've used it a few times in Python, before I found
    out it wasn't a guaranteed behavior by the language.

    > So I come to another conclusion: the indentation syntax will most of the
    > time result in a waste of space. Typically a programmer would want its
    > with-block to end at the end of the current block.


    A test for how often this is needed would be to look in existing
    code for the number of try/finally blocks. I have seen and
    written some gnarly deeply stacked blocks but not often - once
    a year?

    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.

    Andrew
    Andrew Dalke, Jun 4, 2005
    #14
  15. Andrew Dalke wrote:
    > On Sat, 04 Jun 2005 10:43:48 -0600, Steven Bethard wrote:
    >
    >>Ilpo Nyyssönen wrote:
    >>
    >>>How about this instead:
    >>>
    >>>with locking(mutex), opening(readfile) as input:
    >>> ...

    >
    >>I don't like the ambiguity this proposal introduces. What is input
    >>bound to?

    >
    > It would use the same logic as the import statement, which already
    > supports an 'as' like this


    Ahh, so if I wanted the locking one I would write:

    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?

    STeVe
    Steven Bethard, Jun 4, 2005
    #15
  16. Guido van Rossum

    Andrew Dalke Guest

    Steven Bethard wrote:
    > Ahh, so if I wanted the locking one I would write:
    >
    > with locking(mutex) as lock, opening(readfile) as input:
    > ...


    That would make sense to me.

    > 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.


    Ahh, you're right. That was an earlier proposal.

    >
    > 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.:


    I would think it's the same as

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

    which appears to map to the first of your alternatives

    > 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)


    That wouldn't work; consider if _opening.__enter__() raised
    an exception. The _locking.__exit__() would never be called,
    which is not what anyone would expect from the intent of
    this PEP.

    > Or maybe:
    >
    > _locking = locking(mutex)
    > _opening = opening(readfile)
    > _exc = (None, None, None)
    > _locking.__enter__()
    > input = _opening.__enter__()


    Same problem here

    > finally:
    > # same order as __enter__ calls this time!!
    > _locking.__exit__(*exc)
    > _opening.__exit__(*exc)


    and the order would be wrong since consider multiple
    statements as

    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.


    > 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?


    Agreed.

    Andrew
    Andrew Dalke, Jun 4, 2005
    #16
  17. Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

    Ilpo Nyyssönen wrote:
    > Nicolas Fleury <_remove_the_> writes:
    >>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
    >> ...

    >
    >
    > How about this instead:
    >
    > with locking(mutex), opening(readfile) as input:
    > ...
    >
    > So there could be more than one expression in one with.


    I prefer the optional-indentation syntax. The reason is simple (see my
    discussion with Andrew), most of the time the indentation is useless,
    even if you don't have multiple with-statements. So in my day-to-day
    work, I would prefer to write:

    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:
    ...

    Regards,
    Nicolas
    Nicolas Fleury, Jun 5, 2005
    #17
  18. Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

    Andrew Dalke wrote:
    > 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()


    That's an interesting point. But I'm not sure if it is a realistic
    error. It would be like using a with-statement without knowing what it
    does. Also, and it seems we agree, these cases are very rare.

    >
    > (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.


    But with both syntaxes you only look at the indentation layout, no? If
    you want to know the "scope" of something as you said, it means you have
    already scan its "with" statement. You only need after that to look at
    the indentation layout, as with indentation syntax.

    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.

    > A test for how often this is needed would be to look in existing
    > code for the number of try/finally blocks. I have seen and
    > written some gnarly deeply stacked blocks but not often - once
    > a year?
    >
    > That's not to say it's a good indicator. A lot of existing code
    > looks like this


    I agree. It's hard to find a good indicator. In my case I use both my
    Python code (with try/finally typically ending a function) and my C++
    code (with typically no {} block created for RAII object scope). So, my
    conclusion, most of the time the indentation will be useless.

    > 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


    Totally agree. The with-statement will open the door to new programming
    patterns in Python and it's hard to tell from status quo how much it
    will be used.

    Regards,
    Nicolas
    Nicolas Fleury, Jun 5, 2005
    #18
  19. Nicolas Fleury wrote:
    > I prefer the optional-indentation syntax. The reason is simple (see my
    > discussion with Andrew), most of the time the indentation is useless,
    > even if you don't have multiple with-statements. So in my day-to-day
    > work, I would prefer to write:
    >
    > def getFirstLine(filename):
    > with opening(filename) as file
    > return file.readline()
    >
    > than:
    >
    > def getFirstLine(filename):
    > with opening(filename) as file:
    > return file.readline()


    One of the beauties of PEP 343 is that it can be explained simply in
    terms of current Python syntax. The expression:

    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

    P.S. I think it's a great sign that people are mainly squabbling about
    syntax here. More likely than not, Guido's already made his mind up
    about the syntax. So, since no one seems to have any real problems with
    the semantics, I'm hopeful that we'll get a direct implementation of PEP
    343 in the next Python release. =)
    Steven Bethard, Jun 5, 2005
    #19
  20. Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

    Steven Bethard wrote:
    > 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...


    Yes. I totally agree with the syntax in the PEP, it provides a
    necessary feature. I'm just suggesting to make the indentation
    *optional*, because most of the time it is not necessary.

    > 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.


    Since the current syntax would be there, the no-indentation syntax can
    be explained in terms of the indentation syntax:

    """
    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...

    > P.S. I think it's a great sign that people are mainly squabbling about
    > syntax here. More likely than not, Guido's already made his mind up
    > about the syntax. So, since no one seems to have any real problems with
    > the semantics, I'm hopeful that we'll get a direct implementation of PEP
    > 343 in the next Python release. =)


    It's important to note that nobody is against the PEP syntax. We are
    only talking about adding things to it (optional indentation, or
    multiple-as as with import).

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

    Regards,
    Nicolas
    Nicolas Fleury, Jun 5, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Delaney, Timothy C (Timothy)
    Replies:
    2
    Views:
    256
    Mike Meyer
    Jun 6, 2005
  2. Ron Adam

    PEP 343, second look

    Ron Adam, Jun 22, 2005, in forum: Python
    Replies:
    2
    Views:
    305
    Ron Adam
    Jun 22, 2005
  3. falcon
    Replies:
    0
    Views:
    295
    falcon
    Aug 4, 2005
  4. falcon
    Replies:
    0
    Views:
    257
    falcon
    Aug 5, 2005
  5. Rk Ch
    Replies:
    3
    Views:
    94
    Damjan Rems
    Apr 30, 2008
Loading...

Share This Page