Ordering python sets

[Lie Ryan]

On Mon, 27 Oct 2008 13:18:43 -0700, bearophileHUGS wrote:

> So I don't accept so much different data structures to have the 
> same name

You need to adjust the current mindset slightly (but in an important way 
to understand the "why" behind this idea). The current notion is: list 
and dict is a data structure. With this idea, list and dict is an 
abstract type, not a data structure. array, linked list, binary tree, red-
black tree, hashed are data structure. We create a data structure by 
passing the data structure's identifier string to a factory function 
provided by the abstract type.

There are two possible syntax sugar:
a = list.bintree([...])
b = list([...]) # also for backward compat, have reasonable default

In short, the data structures doesn't share the same name, the abstract 
data-type does. The suggestion is to change the place where we define the 
what data structure to use.

> Said that, for a high-level language like Python I can see another
> possible solution. To have a type that contains several kinds of data
> structures, for example a "dict" that contains a hash implementation, a
> red-black tree, etc. Such data structure can use a small part of the
> computational power given to it to collect statistics usages of each
> object (or each variable, that may contain in succession several ojects
> of the same type). Such data structure can then at run time adapt
> dynamically, chosing to use the implementation fitter for the specific
> usage of each object or variable (the programmer can give hints of
> course, or sometimes even coerce the usage a specific implementation).
> (such statistics can also be saved on disk to be used for the successive
> run of the program, to help them work well from the start too, and not
> just after a while). If this capability works well in practice, then it
> can solve the problem you were talking about, I think.
> 
> I presume data structures in future high-level languages will be quite
> more able to adapt themselves to their usages. Today it's the second
> time I talk about future programming languages :-)

Although you said you disagree with the general idea, you actually take 
the idea two steps further, I take that as an implicit agreement to 
several parts of the idea.