[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