[njharman]

I've never understood peoples confusion about function defaults.

They are part of function definition, they aren't in the function body. You should expect them to be "executed" when the function is defined.

[Scarblac]

Or they could have been part of the function call, and run when the function is called without that argument.

[klyrs]

You want Python to be how much slower now?

[Scarblac]

This isn't about what I want, just noting that the other way around could sound just as intuitive. Anyway, it's awfully slow already, how much can it hurt ;-)

[kerkeslager]

This is a terrible excuse. Quickly doing the wrong thing isn't optimization.

[klyrs]

The language spec isn't wrong, you just don't like it.

[kerkeslager]

The language spec isn't right you just like it.

Sure, there are a lot of subjective aesthetics that go into the spec, but in this case, there are objective reasons for not liking this. It's a well-known footgun that causes bugs. And it's almost never what you want, so you end up doing something like this:

    def f(xs = None):
        # Are these two lines actually faster than the
        # interpreter creating defaults at call time?
        if xs is None:
            xs = []

        ...

Do you have any reasons at all for defending this decision?

[klyrs]

>

   # Are these two lines actually faster than the
   # interpreter creating defaults at call time?

You're proposing that the interpreter add a check for every default parameter in every function signature; that it should optionally fire off arbitrary code for each and every one. And when you consider that high-performance Python involves writing C extensions, your proposal would be to move that check out of the compiled code and into the slow interpreted space is, yes, a major performance hit.