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 terry.reedy
Recipients rhettinger, serhiy.storchaka, sir-sigurd, terry.reedy
Date 2017-08-05.04:08:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1501906107.31.0.445930663834.issue31108@psf.upfronthosting.co.za>
In-reply-to
Content
On my particular Win 10 machine with 3.6, the times are 1.52 and 2.14.  But to me, the times are irrelevant.  A performance enhancement, by definition, should not change computational results, but this does. If an iterator is a standard iterator, then 'x in iterator' runs the iterator until x is found or iterator is exhausted.  The only current code that properly uses this operation on an iterator must be depending on the behavior.

So while the change might fix some buggy code, it would break good code and divide 'iterator' into two subgroups: standard iterator and contained iterator.  That is turn would require us to documents that while generators remain standard iterators, builtin collection iterators were now contained iterators.  This is confusion we should not inflict on users.

This should be rejected, as we have done with all other proposals to add features to iterators that only apply to a subset.  (The apparently exception, __length_hint__ was defined to not necessarily be accurate, so that there is effectively a default __length_hint__ for all iterators, lambda self: n, where n depends on the caller.)
History
Date User Action Args
2017-08-05 04:51:54terry.reedyunlinkissue31108 messages
2017-08-05 04:08:27terry.reedysetrecipients: + terry.reedy, rhettinger, serhiy.storchaka, sir-sigurd
2017-08-05 04:08:27terry.reedysetmessageid: <1501906107.31.0.445930663834.issue31108@psf.upfronthosting.co.za>
2017-08-05 04:08:27terry.reedylinkissue31108 messages
2017-08-05 04:08:26terry.reedycreate