IssueRaiser

Probably this stems from the typical C-way of error-reporting out of a for-loop, which is to terminate earlier than the "regular loop con...

Probably this stems from the typical C-way of error-reporting out of a for-loop, which is to terminate earlier than the "regular loop condition", and hence a second test for the loop-condition can easily be used to check for abnormal termination... int i; for (i=0; i<length; i++) { if (is_broken(element[i])) break; process(element[i]); } &#x2F;* if everything went fine, i == length, else we broke out early *&#x2F; if (i < length) { fprintf(stderr,"Something was broken."); return -1; } Whereas the Python version obviously doesn't make sense in a pythonesque program iterating over sets of elements. for i in [1,2,3] : do_something(i) # ..now i is 3, not 4... obviously

Posted by cnvogel on Jan 18, 2015, 8:11 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.8,000 issues0 comments

reliability (Other)

Probably this stems from the typical C-way of error-reporting out of a for-loop, which is to terminate earlier than the "regular loop con...

cnvogelJan 18, 2015, 8:11 PM

Probably this stems from the typical C-way of error-reporting out of a for-loop, which is to terminate earlier than the "regular loop condition", and hence a second test for the loop-condition can easily be used to check for abnormal termination... int i; for (i=0; i<length; i++) { if (is_broken(element[i])) break; process(element[i]); } &#x2F;* if everything went fine, i == length, else we broke out early *&#x2F; if (i < length) { fprintf(stderr,"Something was broken."); return -1; } Whereas the Python version obviously doesn't make sense in a pythonesque program iterating over sets of elements. for i in [1,2,3] : do_something(i) # ..now i is 3, not 4... obviously

Comments (0)

No comments yet. Start the discussion.

Comment on this issue