[Python-ideas] Respectively and its unpacking sentence

[Mirmojtaba Gharibi]

I think a lot of your question are answered in my very first email.
Stuff about initialization. I had initialized my variable, but Sjoerd
dropped it when giving his example. Please refer to the very first email.

Regarding how to explain the behaviour in simple term, I also refer you to
my very first email. Basically it's a pair of (kind of) operators I called
Respectively and unpacking. You can read it more extensively there.

It's supposed that in a pairwise operation like this, you provide identical
length lists. If a and b are different length, my idea is that we just go
as much as the length of the first list in the operation or alternatively
the biggest list and then throw an exception for instance.

On Wed, Jan 27, 2016 at 12:54 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 27 January 2016 at 17:12, Mirmojtaba Gharibi
> <mojtaba.gharibi at gmail.com> wrote:
> > innerProduct = sum(map(operator.mul, a, b))
> > is much more complex than
> > innerProduct += $a * $b
>
> Certainly the second is *shorter*. But it's full of weird "magic"
> behaviour that I don't even begin to know how to explain in general
> terms (i.e., without having to appeal to specific examples):
>
> - Why does += magically initialise innerProduct to 0 before doing the
> implied loop? Would it initialise to '' if a and b were lists of
> strings?
> - What would *= or -= or ... initialise to? Why?
> - What does $a mean, in isolation from a larger expression?
> - How do I generalise my understanding of this expression to work out
> what innerProduct += $a * b means?
> - Given that omitting the $ before one or both of the variables
> totally changes the meaning, how bad of a bug magnet is this?
> - What if a and b are different lengths? Why does the length of the
> unrelated list b affect the meaning of the expression $a (i.e.,
> there's a huge context sensitivity here).
> - How do I pronounce $a? What is the name of the $ "operator". "*" is
> called "multiply", to give an example of what I mean.
>
> Oh, and your "standard Python" implementation of inner product is not
> the most readable (which is a matter of opinion, certainly) approach,
> so you're asking a loaded question. An alternative way of writing it
> would be
>
> innerProduct = sum(x*y for x, y in zip(a, b))
>
> Variable names that aren't 1-character would probably help the
> "normal" version. I can't be sure if they'd help or harm the proposed
> version. Probably wouldn't make much difference.
>
> Sorry, but I see no particular value in this proposal, and many issues
> with it. So -1 from me.
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160127/29f09e02/attachment-0001.html>