functions, optional parameters

[Dave Angel]

On 05/09/2015 11:33 PM, Chris Angelico wrote:
> On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> This is the point where some people try to suggest some sort of complicated,
>> fragile, DWIM heuristic where the compiler tries to guess whether the user
>> actually wants the default to use early or late binding, based on what the
>> expression looks like. "0 is an immutable int, use early binding; [] is a
>> mutable list, use late binding." sort of thing. Such a thing might work
>> well for the obvious cases, but it would be a bugger to debug and
>> work-around for the non-obvious cases when it guesses wrong -- and it will.
>
> What you could have is "late-binding semantics, optional early binding
> as an optimization but only in cases where the result is
> indistinguishable". That would allow common cases (int/bool/str/None
> literals) to be optimized, since there's absolutely no way for them to
> evaluate differently.
>

Except for literals, True, False and None, I can't see any way to 
optimize such a thing.  Just because the name on the right side 
references an immutable object at compile time, it doesn't follow that 
it'll still be the same object later.

Unless late binding means something very different than I understood.

-- 
DaveA