[Python-ideas] Adding collections.abc.Ordered

[Andrew Barnert]

On Nov 7, 2015, at 06:41, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
> Andrew Barnert writes:
>> On Nov 6, 2015, at 21:00, Stephen J. Turnbull <stephen at xemacs.org> 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.

Not very useful, sure—I argued that myself—but how is it dangerous? The only risk here is the risk that comes from adding more code, docs, and complexity to the stdlib.

>> 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)

For, How is that at all useful? What code can you imagine that needs to compare elements from an arbitrary iterable, and would rather have a comparison that's linear in the length of the iterable than none at all?

Second, why list(z for z in self) instead of just list(self) or [z for z in self]? It seems like you're deliberately trying to find the slowest and least straightforward way of implementing it…

But, most importantly, if you want an index method, why aren't you just requiring Sequence, which has one? The notion of index implies the notion of random accessibility—which is exactly what Sequence adds on top of Sized Iterable Container.

Of course there are types for which compare might exist but index might not (e.g., a range of reals, or a set that's only partially ordered), but they're not iterables. (Well, a partially ordered set could Iterate in partially-arbitrary order, but then it's not Ordered in the OP's sense.)

His proposal really does specify exactly what he wants, it's dead simple, and it does all he asks of it. The only question is whether anyone needs it (and, even if they do, whether it needs to be in the stdlib).

> 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".

Well, yes, what he _really_ requires here is an ordered, _unique_, finite, repeatable iterable. Adding a test for Ordered is clearly insufficient for that, and doesn't seem particularly useful. But again, that doesn't mean that Ordered is underspecified in any way; it just means he doesn't have a good use case for it.

> I don't think thought about how this collections.abc.Ordered should
> interact with objects that could be considered to represent multisets.
> Do you?

I'm not sure what you're asking here. But clearly list, OrderedCounter, and a SortedMultiSet type are all ordered, and can all be used to represent multisets in rather obvious ways. And the only way his proposed Ordered has to interact with them is that they all inherit from or get registered with the Ordered ABC (and aren't lying about it).

Of course your proposal for some kind of sorting-related ABC that generates the sort order from indexes would have a problem with multisets, and especially with list as you mentioned above, but that has nothing to do with his proposal.

>> 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.

OK, they're perfectly reasonable types for __slots__, despite the fact that no useful, acceptably efficient, or in any way desirable comparison function exists. Better?

> 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".