Addition appeared in imperative languages first. Does that mean addition is imperative?

It's great that functional languages were first to catch onto these ideas, but that doesn't mean that anything else that uses them becomes functional. The interface isn't even functional, since in code like

    foo = iter((1, 2, 3))
    {x for x in foo}

`foo` is mutated. No "true" functional language would accept that ;).

Addition, as implemented by Python, is functional. There are no side effects. A fully imperative encoding of addition would be eg. the x86 add instructions. John Backus gave us "functional" arithmetic with Fortran, but realised all values should should be treated this way, not just numbers. I take your point about the iterators being mutated and the loss referential transparency. That's certainly not functional programming.

> Addition, as implemented by Python, is functional.

Sure, but Python wasn't the first imperative programming language. (An aside: that's not strictly true anyway; the error thrown when you do 1 + [] is a side effect.)

Functional typically implies higher-order functions, of which there are none in that Python code.

There is no well defined definition of functional programming. Since almost every mainstream imperative language supports higher-order functions, I would suggest that criteria is inadequate. A better definition is programming without side-effects.

Output is a side effect.

Not in Haskell and other pure languages. Pure functional programming is used to construct larger programs from smaller ones, which only when finally executed by the runtime produce output.

Are there any programs that produce output before they are executed?

It is not easy describing pure functional programming in two sentences. I encourage you to read up on it yourself. Again, IO is not a side-effect in pure languages such as Haskell. And again, the absence of side-effects best defines functional programming, not any particular feature, which imperative languages can and do steal.