Hi My name is Juan Carlos Rodrigo, and I love Python.
It is the most impressive and usefull language that
I have ever seen.
I am studing, at http://www.uoc.edu, an Information
Technology Postgraduate. And I have programmed some
REXX applications in my past Jobs (So I love python,
no more ENDS).
** Reposting from Python-Dev with some more comments.
--------8<--------8<--------8<--------8<--------8<--------8<--------
Python 2.4 | 7.3 The for statement:
-----------------------------------
for_stmt ::= "for" target_list "in" expression_list ":"
suite ["else" ":" suite]
New for statement:
------------------
for_stmt ::= "for" target_list "in" expression_list
[ "and" expression ] ":"
suite ["else" ":" suite]
** If the expression evaluates to False before
entering the for, jump else.
** If the expression is evaluated to False after
the first iteration, break.
So ¿What we can do with this new for?,
and ¿It is going to avoid line exceed?:
"My second remark is that our intellectual powers are rather
geared to master static relations and that our powers to
visualize processes evolving in time are relatively poorly
developed." [1]
It is easier if we see it beforehand:
-------------------------------------
leave = False
alist = [1,2,3,3,4,5,6,7 ,8,9]
for item in alist and not leave:
if item is 1: leave = True
Avoiding code exceed:
---------------------
a = 1
b = 2
c = 3
alist = [1,2,3,4,5,6,7,8 ,9]
for item in alist and a < 2 and b < 3 and c < 4:
if item == 3: a += 1
if item == 2: b += 1
if item == 1: c += 1
print "%d %d %d" % (a,b,c)
# three lines off (25% less on breaks)
Other features and the else:
----------------------------
alist = [1,2,3]
enter = False
if list[0] == 4:
enter = True
for item in alist and enter:
print item
else:
print "No account"
The real problem:
-----------------
"The exercise to translate an arbitrary flow diagram more or
less mechanically into a jump-less one, however, is not to be
recommended." [1]
Ok, it's not recommended, at large, but Python should make it possible,
and then the people will choose.
[1] Go To Statement Considered Harmful
Edsger W. Dijkstra
PD: Your work is impressive, thanks.
--------8<--------8<--------8<--------8<--------8<--------8<--------
+++ Andrew Koenig wrote:
[color=blue]
> for_stmt ::= "for" target_list "in" expression_list
> [ "and" expression ] ":"
> suite ["else" ":" suite][/color]
[color=blue]
> It can't work. The expression_list could be just a variable, as[/color]
could the[color=blue]
> expression, in which case you get[/color]
[color=blue]
> "for" target_list "in" variable "and" variable ":"[/color]
Considering that your for definition is not correct.
[color=blue]
> and, of course[/color]
[color=blue]
> variable "and" variable[/color]
[color=blue]
> is already an expression. So it's ambiguous.[/color]
No my definition has no ambiguity in it and your idea does
not work as you think, because is not an expression as you
incorrectly wrote out, is an expression_list :
[color=blue][color=green][color=darkred]
>>> leave = True
>>> l = [1,2,3,4]
>>> form item in l and leave:[/color][/color][/color]
File "<stdin>", line 1
form item in l and leave:
And your example what really does is iterating over the
expression_list (BTW: "and" cannot be used as you point out):
[color=blue][color=green][color=darkred]
>>> leave = True
>>> l = [1,2,3,4]
>>> for item in l, leave:[/color][/color][/color]
.... print item
....
[1, 2, 3, 4]
True
+++ Nick Coghlan wrote:
[color=blue]
> Interesting idea, but not really needed given the
> existence of the break statement:[/color]
[color=blue]
> for item in alist:
> if item is 1:
> break[/color]
Well Nick the point here is to have the possibility
to leave for loops without using the break statement,
and of course use breaks too.
+++ Nick Coghlan wrote:
[color=blue]
> All non-sequential control structures are merely constrained ways of
> using goto (the underlying machine code will devolve into conditional[/color]
[color=blue]
> and unconditional branches and jumps - i.e. goto's).[/color]
No doubt Nick, but were are programming on a very, very high level
language.
_______________ _______________ ______________[color=blue]
> 'break' is a highly constrained form of goto and a fundamental part
> of structured programming (as is 'continue')[/color]
Well you are expressing it better than I am.
[color=blue]
> I used to share your sentiment regarding break and continue -
> experience (especially Python experience) has convinced me otherwise.[/color]
[color=blue]
> Python embraces the concept of breaking out of a loop to the point
> that it even has an 'else' clause on loop structures that is executed[/color]
[color=blue]
> only if the loop is exited naturally rather than via a break[/color]
statement.
And It will be better with by for breaking possibilities.
[color=blue]
> Regardless of whether you personally choose to use break and
> continue, the existence of those statements is the main reason
> that the addition of a flag condition to for loops is highly
> unlikely.[/color]
¿Why is that C has both break, continue and in for breaking
capabilities?
Thanks for your comments.
It is the most impressive and usefull language that
I have ever seen.
I am studing, at http://www.uoc.edu, an Information
Technology Postgraduate. And I have programmed some
REXX applications in my past Jobs (So I love python,
no more ENDS).
** Reposting from Python-Dev with some more comments.
--------8<--------8<--------8<--------8<--------8<--------8<--------
Python 2.4 | 7.3 The for statement:
-----------------------------------
for_stmt ::= "for" target_list "in" expression_list ":"
suite ["else" ":" suite]
New for statement:
------------------
for_stmt ::= "for" target_list "in" expression_list
[ "and" expression ] ":"
suite ["else" ":" suite]
** If the expression evaluates to False before
entering the for, jump else.
** If the expression is evaluated to False after
the first iteration, break.
So ¿What we can do with this new for?,
and ¿It is going to avoid line exceed?:
"My second remark is that our intellectual powers are rather
geared to master static relations and that our powers to
visualize processes evolving in time are relatively poorly
developed." [1]
It is easier if we see it beforehand:
-------------------------------------
leave = False
alist = [1,2,3,3,4,5,6,7 ,8,9]
for item in alist and not leave:
if item is 1: leave = True
Avoiding code exceed:
---------------------
a = 1
b = 2
c = 3
alist = [1,2,3,4,5,6,7,8 ,9]
for item in alist and a < 2 and b < 3 and c < 4:
if item == 3: a += 1
if item == 2: b += 1
if item == 1: c += 1
print "%d %d %d" % (a,b,c)
# three lines off (25% less on breaks)
Other features and the else:
----------------------------
alist = [1,2,3]
enter = False
if list[0] == 4:
enter = True
for item in alist and enter:
print item
else:
print "No account"
The real problem:
-----------------
"The exercise to translate an arbitrary flow diagram more or
less mechanically into a jump-less one, however, is not to be
recommended." [1]
Ok, it's not recommended, at large, but Python should make it possible,
and then the people will choose.
[1] Go To Statement Considered Harmful
Edsger W. Dijkstra
PD: Your work is impressive, thanks.
--------8<--------8<--------8<--------8<--------8<--------8<--------
+++ Andrew Koenig wrote:
[color=blue]
> for_stmt ::= "for" target_list "in" expression_list
> [ "and" expression ] ":"
> suite ["else" ":" suite][/color]
[color=blue]
> It can't work. The expression_list could be just a variable, as[/color]
could the[color=blue]
> expression, in which case you get[/color]
[color=blue]
> "for" target_list "in" variable "and" variable ":"[/color]
Considering that your for definition is not correct.
[color=blue]
> and, of course[/color]
[color=blue]
> variable "and" variable[/color]
[color=blue]
> is already an expression. So it's ambiguous.[/color]
No my definition has no ambiguity in it and your idea does
not work as you think, because is not an expression as you
incorrectly wrote out, is an expression_list :
[color=blue][color=green][color=darkred]
>>> leave = True
>>> l = [1,2,3,4]
>>> form item in l and leave:[/color][/color][/color]
File "<stdin>", line 1
form item in l and leave:
And your example what really does is iterating over the
expression_list (BTW: "and" cannot be used as you point out):
[color=blue][color=green][color=darkred]
>>> leave = True
>>> l = [1,2,3,4]
>>> for item in l, leave:[/color][/color][/color]
.... print item
....
[1, 2, 3, 4]
True
+++ Nick Coghlan wrote:
[color=blue]
> Interesting idea, but not really needed given the
> existence of the break statement:[/color]
[color=blue]
> for item in alist:
> if item is 1:
> break[/color]
Well Nick the point here is to have the possibility
to leave for loops without using the break statement,
and of course use breaks too.
+++ Nick Coghlan wrote:
[color=blue]
> All non-sequential control structures are merely constrained ways of
> using goto (the underlying machine code will devolve into conditional[/color]
[color=blue]
> and unconditional branches and jumps - i.e. goto's).[/color]
No doubt Nick, but were are programming on a very, very high level
language.
_______________ _______________ ______________[color=blue]
> 'break' is a highly constrained form of goto and a fundamental part
> of structured programming (as is 'continue')[/color]
Well you are expressing it better than I am.
[color=blue]
> I used to share your sentiment regarding break and continue -
> experience (especially Python experience) has convinced me otherwise.[/color]
[color=blue]
> Python embraces the concept of breaking out of a loop to the point
> that it even has an 'else' clause on loop structures that is executed[/color]
[color=blue]
> only if the loop is exited naturally rather than via a break[/color]
statement.
And It will be better with by for breaking possibilities.
[color=blue]
> Regardless of whether you personally choose to use break and
> continue, the existence of those statements is the main reason
> that the addition of a flag condition to for loops is highly
> unlikely.[/color]
¿Why is that C has both break, continue and in for breaking
capabilities?
Thanks for your comments.
Comment