<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid44B2EB8F.60409@canterbury.ac.nz" type="cite">
<blockquote type="cite">
<pre wrap="">There would be some implementation consequences in terms of speed and
memory usage (we would lose the memory savings and some of the speed-ups
gained in the Py2.5 implementation of sets).
</pre>
</blockquote>
<pre wrap=""><!---->
Is that really necessary? Couldn't the keys and values be
kept in separate arrays, and only allocate the values array
the first time a non-canonical value is inserted?
</pre>
</blockquote>
That would forgo cache locality and would slow-down general purpose
dicts.<br>
<br>
<br>
<blockquote cite="mid44B2EB8F.60409@canterbury.ac.nz" type="cite">
<blockquote type="cite">
<pre wrap="">Guido listed the basic conflicts 1) arbitrary decisions as to which
values to keep, 2) unexpected stings from != and == taking values into
account, 3) operations that don't make sense (__setitem__, setdefault,
etc).
</pre>
</blockquote>
<pre wrap=""><!----> > ...
> assert a|b == b|a, 'commutative property'
> assert (a-b) | (a&b) | (b-a) == a|b, 'whole is the sum of the parts'
These could be resolved by refusing to carry out set
operations on a dict which contains non-canonical values.
</pre>
</blockquote>
<br>
Guido's example specifically demonstrated set-ops on non-canonical
sets. Also, having setops for general dictionaries was listed as one
of the advantages of unification.<br>
<br>
<br>
<br>
Raymond<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>