Mailman 3 May 2005 - Python-Dev

Re: [Python-Dev] PEP 340: Else clause for block statements
by Anders J. Munch May 2, 2005

May 2, 2005

GvR wrote: > [Nick Coghlan] > > Option 2: mimic if semantics > > An 'else' clause on a block statement behaves vaguely like the else clause on > > an if statement - the clause is executed only if the first suite is never > > entered, but no exception occurs (i.e. StopIteration is raised by the first call > > to next). > > Strange because it's different from the behavior of a for loop, and > the block-statement doesn't feel like an if-statement at all. But I > could actually imagine a use case: when acquiring a lock with a > time-out, the else-clause could be executed when the acquisition times > out. > > block locking(myLock, timeout=30): > ...code executed with lock held... > else: > ...code executed if lock not acquired... A file-closing block function has the same need, as does any block function that manages a resource, whose acquisition might fail. A surrounding try/except doesn't quite cut it; the problem is that the try-clause will then also cover the suite. Example: try: in opening('file1') as f1: ... in opening('file2') as f2: ... except IOError: print "file1 not available, I'll try again later" How do I tell try/except that I really only meant to trap opening('file1'), but opening 'file2' is not supposed to fail so I want any exception from that propagated? Better if I could write: in opening('file1') as f1: ... in opening('file2') as f2: ... else: print "file1 not available, I'll try again later" or even in opening('file1') as f1: ... in opening('file2') as f2: ... except IOError: print "file1 not available, I'll try again later" I rather like this version, because it is patently clear what should happen if there is no except-clause: The exception propagates normally. - Anders

5 4

Re: [Python-Dev] PEP 340 - possible new name for block-statement
by Luis P Caamano May 2, 2005

May 2, 2005

On 4/29/05, Reinhold Birkenfeld wrote: > Date: Sat, 30 Apr 2005 00:53:12 +0200 > From: Reinhold Birkenfeld <reinhold-birkenfeld-nospam(a)wolke7.net> > Subject: [Python-Dev] Re: PEP 340 - possible new name for > block-statement > To: python-dev(a)python.org > Message-ID: <d4udl0$7j3$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1 > > > FWIW, the first association when seeing > > block something: > > is with the verb "to block", and not with the noun, which is most displeasing. > > Reinhold > Which is the reason I thought of "bracket" instead. Although it's also a noun and a verb, the verb doesn't imply "stop" like block does. However, because one of the main features of python is that it's easy to read, adding "with" to it makes it very clear as in "bracket_with". Ugly at first, but that's just a matter of familiarity. You never notice that your ugly friend is really that ugly anymore, right? bracket_with foo(arg1, arg2) as f: BLOCK seems very explicit to me. However, I do prefer no keyword at all and that would be my first choice, but if we have to choose a keyword, "block" has that "stop" connotation that will certainly confuse more than a few but I doubt people would go with "bracket_with." I certainly hope no-keyword is possible. -- Luis P Caamano Atlanta, GA USA

1 0

(no subject)
by rijish valoorthodi rajan May 2, 2005

May 2, 2005

hello all I am a member of a team dedicated to make a client server database application and our main concern is the speed with which the system performs. we are very new to python. but after reading a lot of documents and consulting some experts we decided to work it out using PYTHON. we plan to make 2 programs one running in the client systems and one that run in server. can any one please help me by telling the thins that i should take care of while designing the project and what tools and what style we should adopt to make the program optimised. regards

2 1

PEP 340 - possible new name for block-statement
by Guido van Rossum May 2, 2005

May 2, 2005

How about, instead of trying to emphasize how different a block-statement is from a for-loop, we emphasize their similarity? A regular old loop over a sequence or iterable is written as: for VAR in EXPR: BLOCK A variation on this with somewhat different semantics swaps the keywords: in EXPR for VAR: BLOCK If you don't need the variable, you can leave the "for VAR" part out: in EXPR: BLOCK Too cute? :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

15 33

PEP 340: Else clause for block statements
by Nick Coghlan May 2, 2005

May 2, 2005

As yet, I don't have a particularly firm opinion on whether or not block statements should support an 'else:' clause. And there are obviously a great many other questions to be answered about how block statements might work that are more important than this one. Still, I've been tinkering with some ideas for how to approach this, and thought I'd write them up for everyone else's consideration. Option 0: No else clause allowed. Figured I should mention this, since it is Guido's last reported inclination, and my total lack of use cases for the other options below suggests this is the best idea for an initial implementation. Option 1: mimic try, for, while semantics An 'else' clause on a block statement behaves like the else clause on for and while loops, and on try/except statements - the clause is executed only if the managed suite completes 'normally' (i.e. it is not terminated early due to an exception, a break statement or a return statement) Option 2: mimic if semantics An 'else' clause on a block statement behaves vaguely like the else clause on an if statement - the clause is executed only if the first suite is never entered, but no exception occurs (i.e. StopIteration is raised by the first call to next). Option 3: iterator-controlled semantics The iterator is given the ability to control whether or not the else clause is executed (e.g. via an attribute of StopIteration), probably using option 1 above as the default behaviour. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

4 3

PEP 340: syntax suggestion - try opening(filename) as f:
by Michael Spencer May 2, 2005

May 2, 2005

I don't know whether it's true for all the PEP 340 use cases, but the all the current examples would read very naturally if the block-template could be specified in an extended try statement: > 1. A template for ensuring that a lock, acquired at the start of a > block, is released when the block is left: try with_lock(myLock): # Code here executes with myLock held. The lock is # guaranteed to be released when the block is left (even # if by an uncaught exception). > 2. A template for opening a file that ensures the file is closed > when the block is left: try opening("/etc/passwd") as f: for line in f: print line.rstrip() > > 3. A template for committing or rolling back a database > transaction: > try transaction(mydb): > 4. A template that tries something up to n times: > try auto_retry(3): f = urllib.urlopen("http://python.org/peps/pep-0340.html") print f.read() > 5. It is possible to nest blocks and combine templates: try with_lock(myLock): try opening("/etc/passwd") as f: for line in f: print line.rstrip() Michael

5 6