[Python-ideas] Respectively and its unpacking sentence

[Random832]

> On Jan 27, 2016, at 09:12, Mirmojtaba Gharibi <mojtaba.gharibi at gmail.com>
> wrote:
> > I think the component-wise operation is the biggest benefit and a more compact and understandable syntax. 
> > For example, 
> > 
> > innerProduct = sum(map(operator.mul, a, b))
> > is much more complex than
> > innerProduct += $a * $b

Frankly, I'd prefer simply innerProduct = sum($a * $b) - i'm not sure
how you can reasonably define all the semantics of all operators in all
combinations in a way that makes your "+=" work.

Furthermore, I think your expressions could also get hairy.

a = [1, 2]
b = [3, 4]
c = 5
a * $b = [[1, 2]*3, [1, 2]*4]] = [[1, 2, 1, 2, 1, 2], [1, 2, 1, 2, 1, 2,
1, 2]]
$a * b = [[1*[3, 4], 2*[3, 4]] = [[3, 4], [3, 4, 3, 4]]
$a * $b = [1*3, 2*4] = [3, 8]
($a * $b) * c = [3, 8] * 5 = [3, 8, 3, 8, 3, 8, 3, 8, 3, 8] # and let's
ignore the associativity problems for the moment
$($a * $b) * c = $[3, 8] * 5 = [3*5, 8*5] = [15, 40]  # oh, look, we
have to put $ on an arbitrary expression, not just a name

Do you need multiple $ signs to operate on multiple dimensions? If not,
why not?

(Arguably, sequence repeating should be a different operator than
multiplication anyway, but that ship has long sailed)

> > MATLAB has a built-in easy way of achieving component-wise operation and I think Python would benefit from that without use of libraries such as numpy.

On Wed, Jan 27, 2016, at 13:13, Andrew Barnert via Python-ideas wrote:
> Why? What's wrong with using numpy?
> 
> It seems like only problem in your initial post was that you thought
> numpy can't do what you want, when in fact it can, and trivially so.
> Adding the same amount of complexity to the base language wouldn't make
> it any more discoverable--it would just mean that _all_ Python users now
> have the potential to be confused, rather than only Python+numpy users,
> which sounds like a step backward.

My impression is that the ultimate idea is to allow/require/recommend a
post-numpy library to use the same syntax for these semantics, so that
the base semantics with the plain operators are not different between
post-numpy and base python, in order to make post-numpy less confusing
than numpy.

I.e. that the semantics when operating on sequences of numbers ought to
be defined solely by the syntax (not confusing, even if it's more
complex than what we have now), rather than by what library the sequence
object comes from (confusing).