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
http://www.acm.org/classics/oct95/
PD: Your work is impressive, thanks.
8<8<8<8<8<8<
+++ Andrew Koenig wrote:
> for_stmt ::= "for" target_list "in" expression_list
> [ "and" expression ] ":"
> suite ["else" ":" suite]
> It can't work. The expression_list could be just a variable, as
could the
> expression, in which case you get
> "for" target_list "in" variable "and" variable ":"
Considering that your for definition is not correct.
> and, of course
> variable "and" variable
> is already an expression. So it's ambiguous.
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:
>>> leave = True
>>> l = [1,2,3,4]
>>> form item in l and leave:
File "", 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):
>>> leave = True
>>> l = [1,2,3,4]
>>> for item in l, leave:
... print item
...
[1, 2, 3, 4]
True
+++ Nick Coghlan wrote:
> Interesting idea, but not really needed given the
> existence of the break statement:
> for item in alist:
> if item is 1:
> break
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:
> All non-sequential control structures are merely constrained ways of
> using goto (the underlying machine code will devolve into conditional
> and unconditional branches and jumps - i.e. goto's).
No doubt Nick, but were are programming on a very, very high level
language.
> 'break' is a highly constrained form of goto and a fundamental part
> of structured programming (as is 'continue')
Well you are expressing it better than I am.
> I used to share your sentiment regarding break and continue -
> experience (especially Python experience) has convinced me otherwise.
> 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
> only if the loop is exited naturally rather than via a break
statement.
And It will be better with by for breaking possibilities.
> 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.
¿Why is that C has both break, continue and in for breaking
capabilities?
Thanks for your comments.
--
http://mail.python.org/mailman/listinfo/python-list
