PEP 340: syntax suggestion - try opening(filename) as f:
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
[Michael Spencer]
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:
Sorry, this emphasizes the wrong thing. A try-statement emphasizes that the body may fail (and then provides some cleanup semantics). IMO a block-statement, while it has cleanup semantics, should emphasize that the block executes under some kind of supervision. The more I think about it the more I like having no keyword at all (see other messages). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, 29 Apr 2005, Guido van Rossum wrote:
The more I think about it the more I like having no keyword at all (see other messages).
I hope you'll reconsider this. I really think introducing a new statement requires a keyword, for pedagogical reasons as well as readability and consistency. Here's my pitch: All the statements in Python are associated with keywords, except for assignment, which is simple and extremely common. I don't think the block statement is simple enough or common enough for that; its semantics are much too significant to be flagged only by a little punctuation mark like a colon. I can empathize with wanting to avoid a keyword in order to avoid an endless debate about what the keyword will be. But that debate can't be avoided anyway -- we still have to agree on what to call this thing when talking about it and teaching it. The keyword gives us a name, a conceptual tag from which to hang our knowledge and discussions. Once we have a keyword, there can be no confusion about what to call the construct. And if there is a distinctive keyword, a Python programmer who comes across this unfamiliar construct will be able to ask someone "What does this 'spam' keyword mean?" or can search on Google for "Python spam" to find out what it means. Without a keyword, they're out of luck. Names are power. -- ?!ng
At 08:21 PM 4/29/05 -0500, Ka-Ping Yee wrote:
All the statements in Python are associated with keywords, except for assignment, which is simple and extremely common. I don't think the block statement is simple enough or common enough for that; its semantics are much too significant to be flagged only by a little punctuation mark like a colon.
Don't forget the 'as' clause.
I can empathize with wanting to avoid a keyword in order to avoid an endless debate about what the keyword will be. But that debate can't be avoided anyway -- we still have to agree on what to call this thing when talking about it and teaching it.
A "template invocation", perhaps, for the statement, and a "templated block" for the actual block. The expression part of the statement would be the "template expression" which must result in a "template iterator".
The keyword gives us a name, a conceptual tag from which to hang our knowledge and discussions. Once we have a keyword, there can be no confusion about what to call the construct. And if there is a distinctive keyword, a Python programmer who comes across this unfamiliar construct will be able to ask someone "What does this 'spam' keyword mean?" or can search on Google for "Python spam" to find out what it means. Without a keyword, they're out of luck. Names are power.
help(synchronized) or help(retry) would doubtless display useful information. Conversely, try Googling for Python's "for" or "if" keywords, and see if you get anything useful -- I didn't.
On Fri, 29 Apr 2005, Phillip J. Eby wrote:
At 08:21 PM 4/29/05 -0500, Ka-Ping Yee wrote:
All the statements in Python are associated with keywords, except for assignment, which is simple and extremely common. I don't think the block statement is simple enough or common enough for that; its semantics are much too significant to be flagged only by a little punctuation mark like a colon.
Don't forget the 'as' clause.
It's optional, and you have to skip an arbitrarily long expression to get to it.
if there is a distinctive keyword, a Python programmer who comes across this unfamiliar construct will be able to ask someone "What does this 'spam' keyword mean?" or can search on Google for "Python spam" to find out what it means. Without a keyword, they're out of luck. Names are power.
help(synchronized) or help(retry) would doubtless display useful information.
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.
Conversely, try Googling for Python's "for" or "if" keywords, and see if you get anything useful -- I didn't.
I tried some of my favourite Python keywords :) and found that the following searches all successfully turn up information on the associated kinds of Python statements in the first couple of hits: python if python else python del python while python assert python yield python break python continue python pass python raise python try python finally python class python for statement python return statement python print statement -- ?!ng
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 | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
[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/)
participants (5)
-
Guido van Rossum -
Ka-Ping Yee -
Michael Spencer -
Nick Coghlan -
Phillip J. Eby