I don't think it's a good idea.

Example in the current main is clear and short. The stdlib here is to be used, if people don't know about operator.mul - it's a good opportunity to learn.

@AlexWaygood Since you reacted with 👍, what do you think?

@python/editorial-board What would be the recommendation in general for such snippets? do we want to introduce more notion in a "roughly equivalent" snippet or should such snippets be as pure as possible (and copy-pastable directly?)

Honestly I don’t think this is a good question for the EB, each case is
likely different.

Fair enough. Sorry for the ping!

For me, I'm fine to merge this change so that one can just C/C the code without the needs to import operator, but I'm also fine with keeping the operator since it gives the possibility of knowing about operator.mul and map(strict=True) (this one is for me).

So, while I approved the PR, I'll wait for Alex's opinion as well.

I'm disinclined to accept this edit because it doesn't look nice. It adds tuple unpacking, introduces two new variables, and forces the reader to relate the px and py back to the inputs p and q. None of that is hard, but then the original wasn't hard either. Also, the original lived for a long time in the itertools docs and no one ever reported difficulty understanding it. So, I don't think there is a real problem to be solved here.

Also, I like the current version because the words in the rough equivalent match the words in the preceding text:

sum()            Return the sum of values 
mul()            of products
map(..., p, q)   from two iterables *p* and *q*.    

Also ISTM that the function being described is simple to grasp. When people see sumprod() in Excel, the name itself suffices for an explanation. If this were a more challenging, we could break it down further:

def sumprod(p, q):
    total = 0
    for x, y in zip(p, q, strict=True):
        total += x * y
    return total

But I think that would insult the intelligence of our readers and not raise them up from where they began.

Looking back at the thread, no one really supports this edit. skirpichev doesn't think it is a good idea. carol says to leave as-is will possible further elaboration. picnixz is neutral. And I'm against it as well. So marking as closed and thanking everyone for looking at this.