[Python-ideas] binding vs rebinding

Chris Rebert pyideas at rebertia.com
Thu Feb 5 22:16:12 CET 2009

On Thu, Feb 5, 2009 at 5:22 AM, spir <denis.spir at free.fr> wrote:
> Hello,
> I wonder why there is no difference in syntax between binding and rebinding. Obviously, the semantics is not at all the same, for humans as well as for the interpreter:
> * Binding: create a name, bind a value to it.
> * Rebinding: change the value bound to the name.
> I see several advantages for this distinction and no drawback. The first advantage, which imo is worthful enough, is to let syntax match semantics; as the distinction *makes sense*.
> A nice side-effect would be to allow detection of typographic or (human ;-) memory errors:
> * When an error wrongly and silently creates a new name instead of launching a NameError exception. A distinct syntax for rebinding would prevent that.
> * When an error wrongly and silently rebinds an existing name instead of launching a NameError exception. A distinct syntax for (first) binding would prevent that.
> No need, I guess, to insist on the fact that such errors sometimes lead to long and difficult debugging precisely for they are silent. This, because in all cases "a=1" is a valid instruction, as there is no distinction between binding and rebinding.
> I suspect a further advantage may be to get rid of "global" and "nonlocal" declarations -- which, as I see it, do not at all fit the python way. I may be wrong on that, still it seems such declarations are necessary only because of the above distinction lacking. My rational on this is:
> * It is very common and helpful to allow a local variable beeing named identically as another one in an external scope.
> * There is no binding/redinding distinction in python syntax.
> * So that whenever a name appears on the left side of an assignment, inside a non-global scope, there is no way to know whether the programmer intends to create a local name or to access a possibly existing external name.
> * To resolve this ambiguity, python adopts the rule of creating a local name.
> * Thus, it becomes impossible to rebind an external name from a local scope. Which is still useful in rather rare, but relevant, use cases.
> * So that 'global', and later 'nonlocal', declarations had to be introduced in python.
> (I tried to be as clear and step-by-step as I can so that this reasoning can easily be refuted if ever it holds errors I cannot see.)
> It seems that if ever the second step would not hold, then there would be no reason for such declarations. Imagine that rebinbing is spellt using ':='. Then, from a non-glocal scope:
> * a=1 causes creation of a local name
> * a:=1 rebinds a local name if exists, or rebinds an external name if exists (step-by-step up to module level scope), or else launches NameError.
> There may be reasons why such a behaviour is not the best a programmer would expect: I wait for your comments.
> Obviously, for the sake of compatibility, this is more a base for discussion, if you find the topic interesting, than for a proposal for python 9000...

It was proposed and rejected for Python 3000, so it's unlikely (though
not impossible) to be changed. See PEP 3099
(http://www.python.org/dev/peps/pep-3099/ : "There will be no
alternative binding operators such as :=") and
I haven't read the thread to see what the reasoning was, but I trust
Guido's judgement,


Follow the path of the Iguana...

More information about the Python-ideas mailing list