Stargaming added the comment: Later on, when Greg mentions the current for/if performance asymmetry, Guido states:
> Fair enough. So maybe *you* can contribute a patch? I don't read this as a rejection, but of course you're right -- this patch is purely an optimization. As already written in my initial comment (and discussed on the mailing list), there would be no change in behaviour: The change from generic iterator behaviour to specific range performance is transparent to the end-user. I don't see how the other patches interfere with this one. Waiting until the development of the range object itself has a stabilized and we decided upon a member type/API seems sensible. Still, this patch would be valid on its own. Now, your impulse is right: having the performance enhancement in the bug tracker doesn't help much -- we need a resolution for this. If someone could review the patch, tell me about the critical parts or point me to references on how to improve it, I'd be really glad! On the mentioned unit tests: I'm unsure how to verify this behaviour since I expect it to affect runtime *only*. PS. With the new tracker, wouldn't the "resource usage" type fit best? _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1766304> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
