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
--
http://mail.python.org/mailman/listinfo/python-list
