Re: [Python-Dev] Keyword for block statements
Ka-Ping Yee wrote:
The programmer who writes the function used to introduce a block
can hardly be relied upon to explain the language semantics. We
don't expect the docstring of every class to repeat an explanation
of Python classes, for example. The language reference manual is
for that; it's a different level of documentation.
Would 'suite' work as the keyword?
Calling these things 'suite' statements would match the Python grammar, give an
obvious visual indicator through the use of a keyword, reduce any confusion
resulting from the differences between Python suites and Ruby blocks (since the
names would now be different), and avoid confusion due to the multiple meanings
of the word 'block'.
And really, what PEP 340 creates is the ability to have user-defined suites to
complement the standard control structures.
Anyway, here's the examples from the PEP using 'suite' as the keyword:
suite synchronized(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).
suite opening("/etc/passwd") as f:
for line in f:
print line.rstrip()
suite transactional(db):
# Perform database operation inside transaction
suite auto_retry(3, IOError):
f = urllib.urlopen("http://python.org/peps/pep-0340.html";)
print f.read()
suite synchronized_opening("/etc/passwd", myLock) as f:
for line in f:
print line.rstrip()
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 340: Else clause for block statements
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Else clause for block statements
On Sun, May 01, 2005, Nick Coghlan wrote: > > 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. +1 > 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) +0 > 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). -0 > 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. -1 Did you deliberately sort the options this way? ;-) I'm mainly responding to deliver my vote against option 3; I don't care much about the other possibilities. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It's 106 miles to Chicago. We have a full tank of gas, a half-pack of cigarettes, it's dark, and we're wearing sunglasses." "Hit it." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keyword for block statements
[Nick Coghlan] > Would 'suite' work as the keyword? > > Calling these things 'suite' statements would match the Python grammar, Actually that's an argument *against* -- too confusing to have two things we call suite. > give an > obvious visual indicator through the use of a keyword, reduce any confusion > resulting from the differences between Python suites and Ruby blocks (since > the > names would now be different), There's no need for that; they are close enough most of the time any way. > and avoid confusion due to the multiple meanings > of the word 'block'. Actually, in Python that's always called a suite, not a block. (Though the reference manual defines "code block" as a compilation unit.) > And really, what PEP 340 creates is the ability to have user-defined suites to > complement the standard control structures. Give that suite and block are so close in "intuitive" meaning, if there were no convincing argument for either, I still like "block" much better -- perhaps because suite is the technical term used all over the grammar. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Else clause for block statements
[Nick Coghlan] > 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. The more I think about it the more this makes the most sense because it is the easiest to understand. > 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) You'd have to define this very carefully. Because break is implemented by passing StopIteration to the __next__ or __exit__ method (depending on which alternative API we end up picking), and StopIteration is also how these methods signal that the loop is over, it's a little tricky. Assuming we go with __exit__ to pass an exception to the iterator/generator, we could define that the else clause is executed when the __next__ method raises StopIteration -- this would imply exhaustion of the iterator from natural causes. This has the advantage of matching the behavior of a for loop. > 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... But I'm not convinced that this shouldn't be handled with a try/except around it all; the use case doesn't appear all that common, and it scares me that when the lock isn't aquired, this happens entirely silently when there is no else-clause. > 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. A slightly cleaner version would be to have a separate subclass of StopIteration for this purpose. But I see serious problems with explaining when the else-clause is executed, because it's too dynamic. It does solve one problem with option 2 though: if there's no else-clause, and ElseIteration is raised, that could become an error rather than being ignored silently. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Else clause for block statements
Nick Coghlan wrote: > 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) I've always thought that was a particularly unintuitive use of the word 'else', and I'm not sure I'd like it to be extended to any new statements. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340 - possible new name for block-statement
[Phillip] > By the way, I notice PEP 340 has two outstanding items with my name on > them; let me see if I can help eliminate one real quick. > > Tracebacks: it occurs to me that I may have unintentionally given the > impression that I need to pass in an arbitrary traceback, when in fact I > only need to pass in the current sys.exc_info(). I've updated the PEP (tying a couple of loose ends and making the promised change to the new API); I've decided to change the signature of __exit__() to be a triple matching the return value of sys.exc_info(), IOW the same as the "signature" of the raise-statement. There are still a few loose ends left, including the alternative API that you've proposed (which I'm not super keen on, to be sure, but which is still open for consideration). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
