[Python-ideas] Respectively and its unpacking sentence

[Sjoerd Job Postmus]

On Wed, Jan 27, 2016 at 01:19:56AM -0500, Mirmojtaba Gharibi wrote:
> Yes, I'm aware sequence unpacking.
> There is an overlap like you mentioned, but there are things that can't be
> done with sequence unpacking, but can be done here.
> 
> For example, let's say you're given two lists that are not necessarily
> numbers, so you can't use numpy, but you want to apply some component-wise
> operator between each component. This is something you can't do with
> sequence unpacking or with numpy. For example:
> 
> $StudentFullName = $FirstName + " " + $LastName
> 
> So, in effect, I think one big part of is component wise operations.
> 
> Another thing that can't be achieved with sequence unpacking is:
> f($x)
> i.e. applying f for each component of x.

map(f, x)

> 
> About your question above, it's not ambiguous here either:
>  a; b = x1;a + x2;5
> is exactly "Equivalent" to
> a = x1+x2
> b = a + 5

Now that's confusing, that it differs from sequence unpacking.

> 
> Also, there is a difference in style in sequence unpacking, and here.
> In sequence unpacking, you have to pair up the right variables and repeat
> the operator, for example:
> x,y,z = x1+x2 , y1+y2, z1+z2
> Here you don't have to repeat it and pair up the right variables, i.e.
> x;y;z = x1;y1;z1 + x2;y2;z2
> It's I think good that you (kind of) don't break the encapsulation-ish
> thing we have for the three values here. Also, you don't risk, making a
> mistake in the operator for one of the values by centralizing the operator
> use. For example you could make the mistake:
> x,y,z = x1+x2, y1-y2, z1+z2
> 
> Also there are all sort of other things that are less of a motivation for
> me but that cannot be done with sequence unpacking.
> For instance:
> add ; prod = a +;* y  (This one I'm not sure how can be achieved without
> ambiguity)
> x;y = f;g (a;b)
> 
> 
> On Wed, Jan 27, 2016 at 12:57 AM, Sjoerd Job Postmus <sjoerdjob at sjec.nl>
> wrote:
> 
> > On Wed, Jan 27, 2016 at 12:25:05AM -0500, Mirmojtaba Gharibi wrote:
> > > Hello,
> > >
> > > I'm thinking of this idea that we have a pseudo-operator called
> > > "Respectively" and shown maybe with ;
> >
> > Hopefully, you're already aware of sequence unpacking? Search for
> > 'unpacking' at https://docs.python.org/2/tutorial/datastructures.html .
> > Unfortunately, it does not have its own section I can directly link to.
> >
> >     x, y = 3, 5
> >
> > would give the same result as
> >
> >     x = 3
> >     y = 5
> >
> > But it's more robust, as it can also deal with things like
> >
> >     x, y = y + 1, x + 4
> > >
> > > Some examples first:
> > >
> > > a;b;c = x1;y1;z1 + x2;y2;z2
> > > is equivalent to
> > > a=x1+x2
> > > b=y1+y2
> > > c=z1+z2
> >
> > So what would happen with the following?
> >
> >     a; b = x1;a + x2;5
> >
> > >
> > > So it means for each position in the statement, do something like
> > > respectively. It's like what I call a vertical expansion, i.e. running
> > > statements one by one.
> > > Then there is another unpacking operator which maybe we can show with $
> > > sign and it operates on lists and tuples and creates the "Respectively"
> > > version of them.
> > > So for instance,
> > > vec=[]*10
> > > $vec = $u + $v
> > > will add two 10-dimensional vectors to each other and put the result in
> > vec.
> > >
> > > I think this is a syntax that can make many things more concise plus it
> > > makes component wise operation on a list done one by one easy.
> > >
> > > For example, we can calculate the inner product between two vectors like
> > > follows (inner product is the sum of component wise multiplication of two
> > > vectors):
> > >
> > > innerProduct =0
> > > innerProduct += $a * $b
> > >
> > > which is equivalent to
> > > innerProduct=0
> > > for i in range(len(a)):
> > > ...innerProduct += a[i]+b[i]
> > >

Thinking about this some more:

How do you know if this is going to return a list of products, or the
sum of those products?

That is, why is `innerProduct += $a * $b` not equivalent to
`innerProduct = $innerProduct + $a * $b`? Or is it? Not quite sure.

A clearer solution would be

    innerProduct = sum(map(operator.mul, a, b))

But that's current-Python syntax.

To be honest, I still haven't seen an added benefit that the new syntax
would gain. Maybe you could expand on that?

> >
> > From what I can see, it would be very beneficial for you to look into
> > numpy: http://www.numpy.org/ . It already provides inner product, sums
> > of arrays and such. I myself am not very familiar with it, but I think
> > it provides what you need.
> >
> > >
> > > For example, let's say we want to apply a function to all element in a
> > > list, we can do:
> > > f($a)
> > >
> > > The $ and ; take precedence over anything except ().
> > >
> > > Also, an important thing is that whenever, we don't have the respectively
> > > operator, such as for example in the statement above on the left hand
> > side,
> > > we basically use the same variable or value or operator for each
> > statement
> > > or you can equivalently think we have repeated that whole thing with
> > ;;;;.
> > > Such as:
> > > s=0
> > > s;s;s += a;b;c; * d;e;f
> > > which result in s being a*d+b,c*e+d*f
> > >
> > > Also, I didn't spot (at least for now any ambiguity).
> > > For example one might think what if we do this recursively, such as in:
> > > x;y;z + (a;b;c);(d;e;f);(g;h;i)
> > > using the formula above this is equivalent to
> > > (x;x;x);(y;y;y);(z;z;z)+(a;b;c);(d;e;f);(g;h;i)
> > > if we apply print on the statement above, the result will be:
> > > x+a
> > > x+b
> > > x+c
> > > y+d
> > > y+e
> > > y+f
> > > z+g
> > > z+h
> > > z+i
> > >
> > > Beware that in all of these ; or $ does not create a new list. Rather,
> > they
> > > are like creating new lines in the program and executing those lines one
> > by
> > > one( in the case of $, to be more accurate, we create for loops).
> > >
> > > I'll appreciate your time and looking forward to hearing your thoughts.
> >
> > Again, probably you should use numpy. I'm not really sure it warrants a
> > change to the language, because it seems like it would really only be
> > beneficial to those working with matrices. Numpy already supports it,
> > and I'm suspecting that the use case for `a;b = c;d + e;f` can already
> > be satisfied by `a, b = c + e, d + f`, and it already has clearly
> > documented semantics and still works fine when one of the names on the
> > left also appears on the right: First all the calculations on the right
> > are performed, then they are assigned to the names on the left.
> >
> > >
> > > Cheers,
> > > Moj
> >
> > Kind regards,
> > Sjoerd Job
> >