> > If indeed such 3rd party code exists, and we expect we can't get it > > all fixed before 2.4 is released, the tracked_item hack can be used as > > a temporary measure to hunt down all those 3rd party extensions that > > break the abstraction. I propose to issue a warning when it is > > discovered that ob_item != tracked_item. Then in 2.5 we can remove > > the tracked_item feature. > > That is a reasonable transition strategy, take the immediate gain > and then phase out list->tracked_item. The fix for offending code is > a simple rule: if you mess with list->ob_item, then invalidate the > list->allocated field by setting it to -1. Still disagree. What if we have an even better idea next year? Offending code should switch to using the documented list APIs. I think the 'allocated' member (or any other member for that matter) should not be part of the documented API. > Now with a fast PyList_Append(), there is much less of a reason > to want to hack through the abstraction. Still, I'm okay with > allowing tinkering using the above invalidation rule. I'm not. We need to make our abstractions tighter, not looser. --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