Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over "with A(), B() as a, b:") because it has more syntactical similarity to the written-out version. Also, our current uses of "as" all have only one expression on the right. The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at <http://codereview.appspot.com/53094>. If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Hi,
this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing
with A() as a, B() as b:
to be written instead of
with A() as a: with B() as b:
This syntax was chosen (over "with A(), B() as a, b:") because it has more syntactical similarity to the written-out version. Also, our current uses of "as" all have only one expression on the right.
The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at <http://codereview.appspot.com/53094>.
If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage.
cheers, Georg
I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple: with A, B: pass context = A, B with context: pass (I.e. a tuple, or perhaps any iterable, would be a valid context manager.) With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose. Fredrik
FWIW, I prefer Fredrik's wish too. Alex On Sat, May 2, 2009 at 12:26 PM, Fredrik Johansson < fredrik.johansson@gmail.com> wrote:
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Hi,
this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing
with A() as a, B() as b:
to be written instead of
with A() as a: with B() as b:
This syntax was chosen (over "with A(), B() as a, b:") because it has more syntactical similarity to the written-out version. Also, our current uses of "as" all have only one expression on the right.
The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at <http://codereview.appspot.com/53094>.
If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage.
cheers, Georg
I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple:
with A, B: pass
context = A, B with context: pass
(I.e. a tuple, or perhaps any iterable, would be a valid context manager.)
With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose.
Fredrik _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com
Fredrik Johansson schrieb:
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Hi,
this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing
with A() as a, B() as b:
to be written instead of
with A() as a: with B() as b:
I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple:
with A, B: pass
context = A, B with context: pass
(I.e. a tuple, or perhaps any iterable, would be a valid context manager.)
I see; you want to construct your context manager programmatically and pass it to "with" without knowing what is in there. While this would be possible, we have to be aware that with this we would effectively change the context manager protocol, rather like the iterator protocol's __getitem__ alternate realization. This muddies the definition of a context manager. (The interesting thing is that you could already implement *that* version without any new syntactic support, by giving tuples an __enter__/__exit__ method pair.)
With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose.
Not really. Having an unknown number of stacked context managers is not the purpose -- for that, I'd still say a custom nesting context manager is better, because it is also more explicit when created not at the "with" site. (You could even write it as a tuple subclass, if you like the tuple interface.) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
oN Sat, 2 May 2009 at 22:12, Georg Brandl wrote:
I see; you want to construct your context manager programmatically and pass it to "with" without knowing what is in there.
While this would be possible, we have to be aware that with this we would effectively change the context manager protocol, rather like the iterator protocol's __getitem__ alternate realization. This muddies the definition of a context manager.
(The interesting thing is that you could already implement *that* version without any new syntactic support, by giving tuples an __enter__/__exit__ method pair.)
With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose.
Not really. Having an unknown number of stacked context managers is not the purpose -- for that, I'd still say a custom nesting context manager is better, because it is also more explicit when created not at the "with" site. (You could even write it as a tuple subclass, if you like the tuple interface.)
As I understand it, the primary problem the patch Georg is talking about solves is the fact that currently if you pass multiple contexts to contextlib.nested, and one of the later items in the argument list throws an error, the context(s) from the earlier context manager(s) does not get cleaned up properly. This patch solves that problem very neatly. I'm +1 on the patch, including preferring the syntax over the alternative. Georg, maybe you should post the link to the python-ideas discussion? --David
(I still don't really have net access back after moving house - just chiming in briefly via my mobile) Anyway, I think there is one very good reason for NOT defining a multi- with statement in terms of an existing tuple: it gains us nothing except speed over contextlib.nested. The whole point of the new syntactic support is to execute each expression inside the context of the preceding managers. That requirement precludes the idea of using an intermediate tuple, since every expression would have to be evaluated before the tuple could be created. I'm still not 100% convinced the saving in indentation levels due to this change would be worth the increase in complexity and ambiguity though. -- Nick Coghlan, Brisbane, Australia On 03/05/2009, at 6:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Fredrik Johansson schrieb:
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Hi,
this is just a short notice that Mattias Brändström and I have f inished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing
with A() as a, B() as b:
to be written instead of
with A() as a: with B() as b:
I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple:
with A, B: pass
context = A, B with context: pass
(I.e. a tuple, or perhaps any iterable, would be a valid context manager.)
I see; you want to construct your context manager programmatically and pass it to "with" without knowing what is in there.
While this would be possible, we have to be aware that with this we would effectively change the context manager protocol, rather like the iterator protocol's __getitem__ alternate realization. This muddies the definition of a context manager.
(The interesting thing is that you could already implement *that* version without any new syntactic support, by giving tuples an __enter__/ __exit__ method pair.)
With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose.
Not really. Having an unknown number of stacked context managers is not the purpose -- for that, I'd still say a custom nesting context manager is better, because it is also more explicit when created not at the "with" site. (You could even write it as a tuple subclass, if you like the tuple interface.)
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (5)
-
Alex Martelli -
Fredrik Johansson -
Georg Brandl -
Nick Coghlan -
R. David Murray