RetroSearch Browse

Tue Feb 10 11:47:00 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-February/042476.html

> 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.

After adding the warning and commenting the invalidation rule, is it 
okay to check this one in?

>  (I think Tim's earlier attempt had about the same
> performance.)

Right.  Though this one doesn't crash the testsuite and it doesn't
recompute roundupsize() on every call ;-)

> We can't be wishy-washy about this.  Either we allow external code to
> tinker, or we don't.  If, in fact, there is 3rd party code that
> tinkers in illegal ways, we should try to get it fixed, not work
> around it forever.

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.

Raymond Hettinger

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-February/042476.html below:

[Python-Dev] Optimization of the Year