[Python-ideas] with statement: multiple context manager
pyideas at rebertia.com
Sun Mar 1 23:22:56 CET 2009
On Sun, Mar 1, 2009 at 2:14 PM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Mar 1, 2009 at 1:35 PM, Chris Rebert <pyideas at rebertia.com> wrote:
>> On Sun, Mar 1, 2009 at 12:57 PM, Christian Heimes <lists at cheimes.de> wrote:
>>> Chris Rebert wrote:
>>>> While I still mostly like the idea, it does seem to undermine Python's
>>>> uniformity a bit.
>>> I played with both possible versions before I wrote the proposal. Both
>>> ways have their pros and cons. I'm preferring the proposed way::
>>> with a, b as x, d as y:
>>> over the other possibility::
>>> with a, b, c as _, x, y:
>> You misunderstand me. My quibble isn't over the exact syntax (in fact,
>> I completely agree about the superiority of the proposed ordering),
>> but rather that we're introducing syntax to do something that can
>> already be done with a function (nested()) and is /extremely/ similar
>> to another case (parallel for-loop) where we are opting to still
>> require the use of a function (zip()). This proposed asymmetry
>> concerns me.
> Hm. While we can indeed write the equivalent of the proposed "with a,
> b:" today as "with nested(a, b):", I don't think that the situation is
> quite comparable to a for-loop over a zip() call. The nested() context
> manager isn't particularly intuitive to me (and Nick just found a
> problem in a corner case of its semantics). Compared to nested(), I
> find "with a, b:" very obvious as a shorthand for nested
> with a:
> with b:
> --Guido van Rossum (home page: http://www.python.org/~guido/)
Ok, fine by me. Just wanted to ensure the point was brought up and
adaquately responded to.
On another note, someone ought to draft a revision to PEP 343 to
document this proposal.
Follow the path of the Iguana...
More information about the Python-ideas