> > 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. I won't argue about that. > 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. In this case the above "you" is fully undefined. I will archive this discussion for better times when I have spare-cycles. Anygui people is commited to ship just pure python code, and I'm not really a developer for the project, just a jython "consultant". So I will just workaround otherwise, I already knew that, this was mostly a survey, a valuable one and thanks for the answers. My band-width in the near future is for helping with Jython 2.2 and other personal stuff ... Thanks, Samuele.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4