This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Demur Rumed, dino.viehland, rhettinger, serhiy.storchaka
Date 2016-06-07.18:48:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465325288.05.0.278770809584.issue27127@psf.upfronthosting.co.za>
In-reply-to
Content
I don't think this should go forward.  The current FOR_ITER and JUMP_ABSOLUTE combination is very efficient and shouldn't be changed lightly.  It is the inside of the loop that matters -- the GET_ITER step is outside of the loop and isn't expensive.

Also, I really like that GET_ITER and FOR_ITER correspond exactly to our high level understanding of how for-loops operate:

   for x in s:
       f(x)

corresponds to:

   it = iter(s)
   while True:
       try:
           x = next(it)
       except StopIteration:
           break
       f(x)

I really don't think this should be pursued further.  It messes with my understanding of for-loops, it combines features that should remain decoupled, it focuses its efforts on the exterior of the loop, and it alters code that is very mature (having been examined and tweaked by hundreds of your predecessors).
History
Date User Action Args
2016-06-07 18:48:08rhettingersetrecipients: + rhettinger, dino.viehland, serhiy.storchaka, Demur Rumed
2016-06-07 18:48:08rhettingersetmessageid: <1465325288.05.0.278770809584.issue27127@psf.upfronthosting.co.za>
2016-06-07 18:48:08rhettingerlinkissue27127 messages
2016-06-07 18:48:07rhettingercreate