Steven D'Aprano added the comment: On Sat, Oct 04, 2014 at 10:43:02AM +0000, Antoine Pitrou wrote:
> Just because something is discussed doesn't mean it needs a PEP. I know that in general discussions do not need a PEP, but we seem to be rushing awfully fast into writing code before we even know what the code is supposed to do. Perhaps "need a PEP" was too strong, but we surely need to do something to decide on constistent and well-defined behaviour. As you pointed out earlier, Counters aren't precisely multisets, they're more like a hybrid mapping/multiset. It's not clear what behaviour subset and superset should have for such a hybrid. By rushing into code before deciding on what the code is supposed to do, we end up with inconsistent behaviour. Here are a pair of Counters which compare "is subset", but not "is subset or equal" using Ram's patch: py> Counter(a=1, b=0) < Counter(a=2) True py> Counter(a=1, b=0) <= Counter(a=2) False On the other hand, here's a pair which compares "is subset or equal", but not ("is subset" or "equal"): py> Counter(a=0) <= Counter(b=0) True py> (Counter(a=0) < Counter(b=0)) or (Counter(a=0) == Counter(b=0)) False Adding elements with count=0 changes whether a set is a subset or not: py> Counter(a=0) < Counter(b=0) False py> Counter(a=0) < Counter(b=0, c=0) True py> Counter(a=0, b=0) < Counter(b=0, c=0) False I'm not convinced that mixed Counter and regular dict comparisons should be supported, but Ram's patch supports any Mapping type. Is that a good idea? There's been no discussion on that question. Can somebody explain to me what this means? How is this meaningfully a subset operation? py> Counter(a="eggs") < Counter(a="spam") True I supported adding these operations to Counter, but the last thing I want is to enshrine a set of ad-hoc and inconsistent semantics that don't match standard multiset behaviour and are defined by the implementation, instead of having the implementation defined by the desired semantics. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22515> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com