On Saturday, November 7, 2015 at 9:42:19 AM UTC-5, Stephen J. Turnbull wrote:Andrew Barnert writes:
> On Nov 6, 2015, at 21:00, Stephen J. Turnbull <ste...@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.
It's not "dangerous"!! Talk about hyperbole. It's just a question of utility. Personally I would like to see a much richer collections.abc for tests like this.
> 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?
Did you read the original post? All you need is a consistent order. It doesn't matter if the same element turns up twice in order to be Ordered. He can check uniqueness after the fact.
> 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".
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/