[Python-ideas] Support multiplication for sets

[Haoyi Li]

I don't think having itertools.product is a good reason for not
overloading the operator. The same argument could be said against
having listA + listB or listA * 10. After all, those can all be done
with list comprehensions and itertools aswell.

itertools.product(a, b) or a list comprehension work fine for 2 sets,
but if you try doing that for any significant number (which i presume
the OP is), maybe 5 set operations in one expression, it quickly
becomes completely unreadable:

itertools.product(itertools.product(seta, setb.union(setc),
setd.difference(sete))

vs

seta * (setb | setc) * (setd & sete)

We already have operators overloaded for union |, intersect &,
difference -, symmetric difference ^. Having an operator for product
would fit in perfectly if it could be done properly; ensuring that it
is commutative looks non-trivial.

On Fri, Oct 7, 2011 at 7:41 AM, Jakob Bowyer <jkbbwr at gmail.com> wrote:
> Considering any multiplication action on a set is illegal. I don't think it
> will confuse anyone who doesn't know what a set is mathematically.
> On Fri, Oct 7, 2011 at 12:20 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> On 7 October 2011 11:37, Jakob Bowyer <jkbbwr at gmail.com> wrote:
>> > There is that but from a math point of view the syntax a * b does make
>> > sence.
>> > Its slightly clearer and makes more sense to people from outside of a
>> > programming background.
>>
>> I'm not sure I'd agree, even though I come from a maths background.
>> Explicit is better than implicit and all that...
>>
>> Even if it is slightly clearer to some people, I bet there are others
>> (not from a mathematical background) who would be confused by it. And
>> in that case, itertools.product is easier to google for than "*"...)
>> And that's ignoring the cost of implementing, testing, documenting the
>> change.
>>
>> Actually, just to give a flavour of the sorts of design decisions that
>> would need to be considered, consider this:
>>
>> >>> a = set((1,2))
>> >>> b = set((3,4))
>> >>> c = set((5,6))
>> >>> from itertools import product
>> >>> def times(s1,s2):
>> ...    return set(product(s1,s2))
>> ...
>> >>> times(a,times(b,c))
>> {(1, (3, 6)), (2, (3, 5)), (2, (4, 5)), (1, (4, 6)), (1, (4, 5)), (2,
>> (3, 6)), (2, (4, 6)), (1, (3, 5))}
>> >>> times(times(a,b),c)
>> {((2, 4), 6), ((1, 4), 5), ((1, 4), 6), ((2, 3), 6), ((1, 3), 6), ((2,
>> 3), 5), ((2, 4), 5), ((1, 3), 5)}
>> >>>
>>
>> So your multiplication isn't commutative (the types of the elements in
>> the 2 expressions above are different). That doesn't seem intuitive -
>> so maybe a*b*c should be a set of 3-tuples. But how would that work?
>> The problem very quickly becomes a lot larger than you first assume.
>>
>> Operator overloading is used much more sparingly in Python than in,
>> say, C++. It's as much a language style issue as anything else.
>>
>> Sorry, but I still don't see enough benefit to justify this.
>>
>> Paul.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>