A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-January/019123.html below:

[Python-Dev] object equality vs identity, in and dicts idioms and speed

[Python-Dev] object equality vs identity, in and dicts idioms and speedMartin v. Loewis martin@v.loewis.de
Fri, 4 Jan 2002 02:39:23 +0100
> 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



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