[Python-Dev] Re: Sets: elt in dict, lst.include

[Thomas Wouters]

On Tue, Jan 30, 2001 at 05:34:10PM +0000, Finn Bock wrote:

> >Recall that a similar trick is played during list.sort(), replacing the
> >list's type pointer for the duration (to point to an internal "immutable
> >list" type, same as the list type except the "dangerous" slots point to a
> >function that raises an "immutable list" TypeError).  Then no runtime
> >expense is incurred for regular lists to keep checking flags.  I thought
> >of this as an elegant use for switching types at runtime; you may still
> >be appalled by it, though!

> Changing the type of a type? Yuck! 

No, the typeobject itself isn't changed -- that would freeze *all*
dicts/lists/whatever, not just the one we want. We'd be changing the type of
an object (or 'type instance', if you want, but not "type 'instance'"), not
the type of a type.

> I might very likely be reading the CPython sources wrongly, but it seems
> this trick will cause an BadInternalCall if some other C extension are
> trying to modify a list while it is freezed by the type switching trick.
> I imagine this would happen if the extension called:

>   PyList_SetItem(myList, 0, aValue);

Only if PyList_SetItem refuses to handle 'frozen' lists. In my eyes,
'frozen' lists should still pass PyList_Check(), but also PyList_Frozen()
(or whatever), and methods/operations that modify the listobject would have
to check if the list is frozen, and raise an appropriate error if so. This
might throw 'unexpected' errors, but only in situations that can't happen
right now!

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!