On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano <steve+comp.lang.pyt...@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. I personally don't think it'd be that good an idea, but it's a simple enough rule that it wouldn't break anything. As far as anyone's code is concerned, the rule is "late binding, always". In fact, that would be the language definition; the rest is an optimization. (It's like how "x.y()" technically first looks up attribute "y" on object x, then calls the result; but it's perfectly reasonable for a Python implementation to notice this extremely common case and do an "optimized method call" that doesn't actually create a function object.) The simpler the rule, the easier to grok, and therefore the less chance of introducing bugs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
