An identity_list would make for a portable idiom with comparable overhead and will give to the identity case somehow the same speed of the equality case...
And further anygui shows also a possible need for a WeakKeyIdentityDict...
Well, I'd say this is a clear indication that this has to go the path that all library extensions go (or should go): They are implemented in one project, then are used in other projects as well, until finally somebody submits the implementation to the Python core.
In the case of anygui, I'd suggest to include different implementations of the identity_list, and any other specialised container you may have:
- one implementation for C python that works across all Python versions (in C) - if useful, one implementation for Python 2.2 using type inheritance, in C, alternatively, one implementation in pure Python:
class identity_list(list): def __contains__(self, elem): for i in self: if i is elem: return 1 return 0
# need to implement count, index, remove
It turns out that this class is as fast in my benchmark than the Python loop over a builtin list, which is not surprising, as it is the same loop.
- one implementation in Java for use with Jython.
- one implementation in pure Python which works across all Python versions.
The configuration mechanics of anygui should then select an appropriate version.
Experience will tell which of those implementations are used in practice, and which are of use to other packages. That will eventually give a foundation for including one of them into the core libraries. People tend to invent new containers all the time (and new methods for existing containers), and I believe we have to resist the tempation of including them into the language at first sight.
Just make sure that you do *not* put those containers into the location where the Python library will eventually put them, as well; instead if the core provides them, have the configuration mechanics figure to use the builtin type, instead of the anygui-included fallback implementation.
Regards, Martin