Nicolas Fleury wrote:
> 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 en
Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> It's important to note that nobody is against the PEP syntax. We are
> only talking about adding things to it
In think the above is a contradiction in terms.
--
http://mail.python.org/mailman/listinfo/python-list
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
n
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(f
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(serv
Ilpo Nyyssönen wrote:
> Nicolas Fleury <[EMAIL PROTECTED]> 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
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, inpu
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 w
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.
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 imp
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
> cha
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__()?
Ilpo Nyyssönen wrote:
> Nicolas Fleury <[EMAIL PROTECTED]> 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:
>
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 ev
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 __ex
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
--
http://mail.python.org/mailman/listinfo/python-list
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
Nicolas Fleury <[EMAIL PROTECTED]> 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
> ...
H
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
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 equiva
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 cre
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
22 matches
Mail list logo
