> > http://people.freebsd.org/~perky/list-r2.diff.txt > > We have a winner. It has most of the performance benefits with no > space trade-off. (Except on Windows, if I understand Tim's comments.) > It is not as automatic as the previous patch. > The patch had to add code to list_sort() to trap the temporary > alteration of ob_item. If similar tricks get used in extensions, > they will need to add "list->allocated = -1;" to invalidate the > previous allocation size. > > If there are no dissents, I will check this in. I disagree with making the hack of setting list->allocated = -1 an official part of the list object API. The fact that list.sort() does this doesn't mean that other extensions should do this! Since you have ignored repeated requests for real-life examples of code that messes with ob_item outside the core, let's keep the 'allocated' field an internal detail of the list implementation. Then I can ignore the other posts about binary (in)compatibility too. :-) (Otherwise, you would have to write docs before checking it in.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4