[Python-ideas] binding vs rebinding

spir denis.spir at free.fr
Thu Feb 5 14:22:11 CET 2009


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...


PS: As a reference to the thread on the sign ':' at the end of block headlines, the syntactic format I would actually enjoy is:

* binding       name : value
* rebinding     name :: value

la vida e estranya

More information about the Python-ideas mailing list