[Python-Dev] Optimization of the Year
Guido van Rossum
guido at python.org
Tue Feb 10 11:58:07 EST 2004
> > 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/)
More information about the Python-Dev
mailing list