Announcing PEP 3136
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
On 6/30/07, Matt Chisholm <matt-python at theory.org> wrote:
I've created and submitted a new PEP proposing support for labels in Python's break and continue statements. Georg Brandl has graciously added it to the PEP list as PEP 3136:
I think this is a good summary of various proposals that have been floated in the past, plus some new ones. As a PEP, it falls short because it doesn't pick a solution but merely offers a large menu of possible options. Also, there is nothing about implementation yet.
However, I'm rejecting it on the basis that code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code, for example using 'return'.
I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is: while_stmt ::= "while" expression ":" suite ["else" ":" suite] for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite] try1_stmt ::= "try" ":" suite ("except" [expression ["as" target]] ":" suite)+ ["else" ":" suite] ["finally" ":" suite] All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do. -- Hatem Nassrat
On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat <hnassrat@gmail.com> wrote:
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
On 6/30/07, Matt Chisholm <matt-python at theory.org> wrote:
I've created and submitted a new PEP proposing support for labels in Python's break and continue statements. Georg Brandl has graciously added it to the PEP list as PEP 3136:
I think this is a good summary of various proposals that have been floated in the past, plus some new ones. As a PEP, it falls short because it doesn't pick a solution but merely offers a large menu of possible options. Also, there is nothing about implementation yet.
However, I'm rejecting it on the basis that code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code, for example using 'return'.
I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is:
while_stmt ::= "while" expression ":" suite ["else" ":" suite]
for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite]
try1_stmt ::= "try" ":" suite ("except" [expression ["as" target]] ":" suite)+ ["else" ":" suite] ["finally" ":" suite]
All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do.
In English, butterflies are usually a good thing (they mean you'e in love). These else clauses (assuming you're talking about that) have been in the language pretty much forever. The combined except/finally clause is newer, it was added because Java allows it and it was actually a pretty common usage. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I like how python has a minimalistic and powerful syntax (-1 for the break ___ PEP). Also, I really dislike the for/else ambiguity "butterflies". When is the else after a loop executed?1. When the loop isn't entered at all. 2. When the loop terminates through exhaustion of the list (does this include when the list was empty?) 3. When the loop didn't exit because of a break statement. HINTS: The way django does it is opposite the way python does it and there may be more than one correct answer. Any chances of cleaning this one up for python 4? I'm not sure how though I have a few ideas. On Tue, Sep 29, 2009 at 11:47 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat <hnassrat@gmail.com> wrote:
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
On 6/30/07, Matt Chisholm <matt-python at theory.org> wrote:
I've created and submitted a new PEP proposing support for labels in Python's break and continue statements. Georg Brandl has graciously added it to the PEP list as PEP 3136:
I think this is a good summary of various proposals that have been floated in the past, plus some new ones. As a PEP, it falls short because it doesn't pick a solution but merely offers a large menu of possible options. Also, there is nothing about implementation yet.
However, I'm rejecting it on the basis that code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code, for example using 'return'.
I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is:
while_stmt ::= "while" expression ":" suite ["else" ":" suite]
for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite]
try1_stmt ::= "try" ":" suite ("except" [expression ["as" target]] ":" suite)+ ["else" ":" suite] ["finally" ":" suite]
All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do.
In English, butterflies are usually a good thing (they mean you'e in love).
These else clauses (assuming you're talking about that) have been in the language pretty much forever. The combined except/finally clause is newer, it was added because Java allows it and it was actually a pretty common usage.
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com
Yuvgoog Greenle wrote:
I like how python has a minimalistic and powerful syntax (-1 for the break ___ PEP).
Also, I really dislike the for/else ambiguity "butterflies".
When is the else after a loop executed? 1. When the loop isn't entered at all. If you mean because the list / iterator is empty then yes. If you mean something else then explain.
2. When the loop terminates through exhaustion of the list (does this include when the list was empty?) Yes. 3. When the loop didn't exit because of a break statement.
No. This is pretty much the definition of the else statement semantics and are clearly defined.
HINTS: The way django does it is opposite the way python does it and there may be more than one correct answer.
If you mean the Django template language does it differently from Python then you'll have to speak to the Django guys. The Django template language may be inspired by Python and written in Python but it isn't Python and has no obligation to use the same semantics. Python is very clear.
Any chances of cleaning this one up for python 4? I'm not sure how though I have a few ideas.
See above. The else statement semantics for both loops and exception handling are extremely useful and don't need cleaning up. If you have further ideas then the Python-ideas list is the right place to discuss potential language changes or additions. All the best, Michael Foord
On Tue, Sep 29, 2009 at 11:47 PM, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat <hnassrat@gmail.com <mailto:hnassrat@gmail.com>> wrote: > Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote: >> On 6/30/07, Matt Chisholm <matt-python at theory.org <http://theory.org>> wrote: >> > I've created and submitted a new PEP proposing support for labels in >> > Python's break and continue statements. Georg Brandl has graciously >> > added it to the PEP list as PEP 3136: >> > >> > http://www.python.org/dev/peps/pep-3136/ >> >> I think this is a good summary of various proposals that have been >> floated in the past, plus some new ones. As a PEP, it falls short >> because it doesn't pick a solution but merely offers a large menu of >> possible options. Also, there is nothing about implementation yet. >> >> However, I'm rejecting it on the basis that code so complicated to >> require this feature is very rare. In most cases there are existing >> work-arounds that produce clean code, for example using 'return'. > > I agree that this feature will only serve as a quick hack and in many > cases it would be misused and ugly code will be the result. However, > it seems that there are some shortcuts that have sneaked into python > (I am a fairly new Python programmer, only since late 2.4, so don't > shoot me). The specific one of which I speak about is: > > while_stmt ::= "while" expression ":" suite > ["else" ":" suite] > > for_stmt ::= "for" target_list "in" expression_list ":" suite > ["else" ":" suite] > > try1_stmt ::= "try" ":" suite > ("except" [expression ["as" target]] ":" suite)+ > ["else" ":" suite] > ["finally" ":" suite] > > All these else's seem like shortcuts to me. I did find a use for them, > once I found out they existed, but I get butterflies whenever I do.
In English, butterflies are usually a good thing (they mean you'e in love).
These else clauses (assuming you're talking about that) have been in the language pretty much forever. The combined except/finally clause is newer, it was added because Java allows it and it was actually a pretty common usage.
-- --Guido van Rossum (home page: http://www.python.org/~guido/ <http://www.python.org/%7Eguido/>) _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com
------------------------------------------------------------------------
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Yuvgoog Greenle wrote:
I like how python has a minimalistic and powerful syntax (-1 for the break ___ PEP).
Also, I really dislike the for/else ambiguity "butterflies".
Properly understood, no ambiguity. while c: x() is equivalent to hypothetical label z: if c: x() goto: z So while c: x() else: y() is equivalent to label 1: if c: x() goto: 1 else" y() The else clause fires (once) if and when the if/while condition evaluates as false. Break and continue are restricted *unconditional* goto statements, and so *cannot* trigger an else clause. In for loops, the implied condition is 'there is another item in the collection represented by the iterable'. For any more, move to another list. Terry Jan Reedy
Yuvgoog Greenle wrote:
When is the else after a loop executed? 1. When the loop isn't entered at all. 2. When the loop terminates through exhaustion of the list (does this include when the list was empty?) 3. When the loop didn't exit because of a break statement.
1 and 3 are just special cases of 2, when you include the empty-list case. So you're making it more complicated in your mind than it really is.
Any chances of cleaning this one up for python 4?
I doubt that many other people will see anything here that needs cleaning up. -- Greg
This thread moved to python-ideas so please post only there. http://mail.python.org/pipermail/python-ideas/2009-October/005924.html --yuv
On Wed, Sep 30, 2009 at 5:15 PM, Yuvgoog Greenle <ubershmekel@gmail.com>wrote:
I like how python has a minimalistic and powerful syntax (-1 for the break ___ PEP). Also, I really dislike the for/else ambiguity "butterflies". When is the else after a loop executed? 1. When the loop isn't entered at all. 2. When the loop terminates through exhaustion of the list (does this include when the list was empty?) 3. When the loop didn't exit because of a break statement.
HINTS: The way django does it is opposite the way python does it and there may be more than one correct answer.
Django's template language does not have for/else, it has for/empty: http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty This construct did come from an external snippet that used 'else' instead of 'empty'. However when it was moved into Django the 'else' name was specifically rejected because it did the opposite of what for/else does in Python. Karen
participants (7)
-
Greg Ewing -
Guido van Rossum -
Hatem Nassrat -
Karen Tracey -
Michael Foord -
Terry Reedy -
Yuvgoog Greenle