Raymond Hettinger added the comment: It may just be me, but I find the code the be less readable. The presence of the SETREFs in the itertools modules makes it harder for me to count and track all the references to make sure the code is correct. For me, it is an obstacle to maintenance.
The itertools code was carefully thought-out, reviewed, clear (at least to its creator and maintainer), and finely tuned. It has been stable for a very long time and I don't think it should have been changed. The module was designed for high-performance and I'm opposed to adding unnecessary work. As you know, these kind of things are very difficult to run timings on, but it is clear to both of us that the wholesale replacement of Py_DECREF with Py_XDECREF adds unnecessary load to the Branch Target Buffer and to the I-cache. In general, unnecessary work is always a step in the wrong direction, particularly in a module designed for performance. Another occasional issue with the SETREF macro is that gets it the way of trying to defer all decrefs until as late as possible in a function call. The LRU cache is a example of a place where we want to bring the whole data structure into a coherent state prior to any of the decrefs (I even have to do that in the pure python lru cache code to guard against premature re-entrancy). As the creator and principal maintainer of itertools, I'm stating a very strong preference to restore the code in the next() methods. Please don't make this hard for me (When one of the most experienced of the active developers states a strong code preference and gives the reasons for it, there shouldn't have to be struggle to get it done). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26200> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
