[Python-Dev] Deprecating obsolete builtins

Delaney, Timothy C (Timothy) tdelaney at avaya.com
Thu Nov 6 16:46:48 EST 2003


> From: Guido van Rossum [mailto:guido at python.org]
> 
> > > > So I'd actually advocate enhancing intern(), rather 
> than removing
> > > > it, now that interned things are mortal.
> > > 
> > > Have you thought about how to implement that?  And have 
> you calculated
> > > how much memory you would save?
> > 
> > Not yet - musings at the end of the day. As to how much memory - I
> > really don't think it can be calculated - it's so
> > application-dependent.
> 
> Well obviously I meant for *your* app, because you're the one bringing
> this up (I'm highly skeptical of the idea if you hadn't 
> guessed yet :-).

Moved back to python-dev because I've got some actual pseudocode in here ... ;)

I'll follow it up further when I've got a solid use case. I'm also skeptical of the idea, but think it's worth some additional thought. At the moment it's just gut feeling that if we're going to have it at all, it seems that it would be useful for things other than strings.

As for implementation ... something like:

    _INTERN_DICT = WeakKeyValueDictionary()

    def unrestrained_intern (obj):

        # Singletons don't need to be interned
        if obj is None or obj is True or obj is False:
            return obj

        try:
            return intern(obj)
        except TypeError:
            return _INTERN_DICT.setdefault(obj, obj)

    a = (1, 2, 3)
    b = (1, 2) + (3,)
    
    assert unrestrained_intern(a) is unrestrained_intern(b)

Of course, this would require that we could create a weak reference to hashable builtin types like tuple and int. The dictionary holding the objects would need to be weak on both key and value to ensure mortality.

Anyway, there's a lot of flow-on effects there :( and its very much in a fledgling concept phase at the moment.

Tim Delaney



More information about the Python-Dev mailing list