On 25/07/2019 19.41, Andrew Barnert via Python-ideas wrote:
> On Jul 25, 2019, at 09:46, Batuhan Taskaya <isidenti...@gmail.com> wrote:
>> I think it looks very fine when you type {1, 2, 3} * {"a", "b", "c"} and get
>> set(itertools.product({1, 2, 3}, {"a", "b", "c"})). So i am proposing set
>> multiplication implementation as cartesian product.
> I think it might make more sense to reopen the discussion of using @ for
> cartesian product for all containers, for a few reasons.
>
> * The * operator means repeat on lists, tuples, and strings. While there are
> already some operator differences between sets and other containers, but it’s
> generally the types supporting different operators (like sets having | and &,
> and not having +) rather than giving different meanings to the same
> operators. Plus, tuples are frequently used for small things that are
> conceptually sets or set-like; this is even enshrined in APIs like
> str.endswith and isinstance.
>
> * (Ordered) Cartesian product for lists, tuples, iterators, etc. makes just
> as much sense even when they’re not being used as pseudo-sets, ordered sets,
> or multisets, and might even be more common in code in practice (which is
> presumably why there’s a function for that in the stdlib). So, why only allow
> it for sets?
>
> * Cartesian product feels more like matrix multiplication than like scalar
> or elementwise multiplication or repetition, doesn’t it?
Adding @ to sets for Cartesian products *might* be reasonable, but
giving @ a meaning other than matrix multiplication for ordered
collections (lists, tuples) sounds like a terrible idea that will only
cause confusion.
>
> * Adding @ to the builtin containers was already raised during the @
> discussion and tabled for the future. I believe this is because the NumPy
> community wanted the proposal to be as minimal as possible so they could be
> sure of getting it, and get it ASAP, not because anyone had or anticipated
> objections beyond “is it common enough of a need to be worth it?”
>
> I don’t think this discussion would need to include other ideas deferred at
> the same time, like @ for composition on functions. (Although @ on iterators
> might be worth bringing up, if only to reject it. We don’t allow + between
> arbitrary iterables defaulting to chain but meaning type(lhs)(chain(…)) on
> some types, so why do the equivalent with @?)
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LR5PQMLLTBTARLK4NLUYSPIWFRTWJHLA/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VG66TRIL2XYRDDAJKAVMVSQ3CWQH5522/
Code of Conduct: http://python.org/psf/codeofconduct/
