Andrew Barnert writes:
On Nov 6, 2015, at 21:00, Stephen J. Turnbull
wrote:
This ABC would be a tar pit of recriminations between class authors and class clients.
I think you've missed the point of his proposal. It doesn't matter _what_ the order is
That's precisely what I see as problematic, unless the author of the subclass is the same as the author of the code using the subclass.
But, whether the proposal is useful or not, it is sufficiently specified.
I wrote inaccurately, I guess. My contention is that it's more dangerous than useful as currently specified but that could be reversed with additional restrictions.
How would you define the comparison function for OrderedDict in a way that makes any semantic sense? Or, for that matter, list?
Again, bad nomenclature, sorry.[1] I should have used "index". For this application, I have in mind class Ordered: def index(self, key): return list(z for z in self).index(key) def compare(self, key1, key2): return self.index(key1) < self.index(key2) as the default implementation (except that for Amir's application it's .index() that's interesting, not .compare() -- .compare() could be omitted I guess, fn. [1] applies). The problem with list would be that it can have multiple entries of the same value that are not adjacent, of course, but then it wouldn't work for Amir's application anyway. This is part of what I have in mind when I say "underspecified". I don't think thought about how this collections.abc.Ordered should interact with objects that could be considered to represent multisets. Do you?
Surely OrderedDict and list are perfectly reasonable types for __slots__, despite the fact that their comparison function doesn't exist.
If given the above renaming you still say it doesn't exist, I don't understand what you're trying to say. Footnotes: [1] As an excuse for the poor nomenclature, in my field I have to worry about (pre-) ordered structures for which an index function does not exist, thus "comparison function".