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 <[email protected]>
<http://bugs.python.org/issue22515>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
