[Python-ideas] binding vs rebinding

[spir]

Le Fri, 6 Feb 2009 21:47:26 +0100,
"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> a écrit :

> I am treating as "split" languages which distinguish introducing a new
> variable in the current scope from assignment to an existing variable.
> 
> Or, in other words, languages where assignment alone cannot be used to
> create a new local variable.

You are thus enlarging the topic to languages where it is possible to introduce a name without any *explicit* binding. As the title of the thread shows, this was not my initial intention, but I must recognize this is pertinent -- see bottom of the message.

This debate has proved fruitful I guess, thank you very much. Maybe it's time to close it as probably we have explored the topic enough and this aspect of python will not change in a previsible future. I will try sum up fairly the main discussion points -- feel free to criticize ;-).

My startup assertion was that (first) binding and rebinding are conceptually different actions,  worth beeing distinguished in syntax (I wrote: "the distinction *makes sense*"):
* Binding: create a name, bind a value to it.
* Rebinding: change the value bound to the name.
An objection came up that both can be seen as "bind a name to a value". We can nevertheless assume, as there was no further debate on this point, that in most cases and/or for most programmers these actions have a different meaning. Maybe there should be more material to state on that point.

I also asserted that these actions are also different at the interpreter level. This proved to be wrong, which someone showed by providing matching bytecodes. [Is this a consequence that namespaces are implemented as dicts? I cannot imagine, at the underlying level, how adding an entry to a hash table can be the same as changing an entry's value.]

Among possible advantages of the distinction counts the detection of name spelling errors by throwing NameError (or AttributeError): thus avoiding both erroneous rebinding of an existing name and erroneous creation of a new name. There was few comment on this point, too. Maybe it does not seem important or, on the contrary, you consider it relevant but obvious enough.

I also expressed the idea that explicit rebinding is so helpful that it may even avoid the need for 'global' and 'nonlocal' declarations. There was some debate about that point, mostly supporting the idea (right?), but also some opposition.

Some talks took place around several coding situations.

for item in container:
	name = <some value dependant on item>
	<further process using name>
The temporary/utility variables in loops revealed a related topic, namely the absence of loop local scopes in python. This launched a short specific debate: there is clearly a need for that, but then it becomes unclear how to later access a value computed in the loop. [There were threads around this on python lists.]

if condition:
	name = value
	do_something(name)
name = value
do_something_else(name)
In the case of a value that has similar meaning and similar use, both in standard flow and a conditioned branch, it is legitimate to use a unique name. I objected that if a case is special, then the name should be, too. An objection to my objection may be summarized as "naming freedom" ;-)

name = ...
name = ...
name = ...
In this state of mind, the above code is perfectly acceptable. Anyway, this is not really an issue, as it can be simply expressed in the frame of binding/rebinding by using the rebinding syntax in following assignments. (Actually, this would even help legibility when assignments are not directly in a row.)

Finally, there was a dense exchange launched by the assumtion that most languages, especially the most used ones, do not allow such a distinction. Which is obviously True (which should not mean Good for pythonists, as shown by the syntactic use of indentation ;-). Marcin enlarged the debate by opposing (name) introduction to rebinding instead: this one distinction is indeed allowed and even enforced by most prominent languages, namely C and successors. I find this observation highly pertinent.
My personal conclusion derives from Marcin's note:
Python was designed to be familiar to C programmers (stated by Guido), adopted its assignment syntax, but got rid of any kind of declaration. As a consequence, there is only one form of name binding left. Languages that have explicit name introduction, with or without implicit default binding, do not need to distinguish rebinding. My point of view is now that declaration free languages like python would better have it; either enforced, or only allowed. Or else we lose all the conceptual and syntactic benefits of such a distinction.

Denis

[Please erase the debate synhesis if ever you reply to the conclusion only.]

------
la vida e estranya