coding style - where to declare variables
steve+comp.lang.python at pearwood.info
Mon Jul 23 06:42:12 EDT 2018
On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> So let me see if I understand your argument...
>> - we should stop using the term "binding", because it means
>> nothing different from assignment;
>> - binding (a.k.a. "assignment") comes from lambda calculus;
>> - which has no assignment (a.k.a. "binding").
> No, that's not what Marko is saying at all. He's pointing out that the
> term "binding" means something completely different in lambda calculus.
Well done in reading Marko's intent. Unfortunately, I'm not as good as
inferring meaning as you seem to be, consequently I had to judge by what
he wrote, not what he meant.
When a writer fails to communicate their intent, that's usually the
failure of the writer, not the reader. We aren't mind-readers and writers
should not blame the reader when they fail to communicate their intended
> The terms "bound variable" and "free variable" in lambda calculus mean
> what in Python we would call a "local variable" vs. a "non-local
Actually, no, they are called "bound variable" and "free variable" in
See also: http://effbot.org/zone/closure.htm
Alas, I don't think Fredrik Lundh got it *quite* right. I think that
globals (and builtins) in Python are "open free variables", as opposed to
nonlocals which are closed. And sadly, the Python glossary currently
doesn't define free variables nor bound variables, or even name binding.
> They have nothing to do with assignment at all.
That's not quite correct either.
Lambda calculus has the concept of a binding operator, which is
effectively an assignment operator: it takes a variable and a value and
binds the value to the variable, changing a free variable to a bound
variable. In other words, it assigns the value to the variable, just like
In Python terms, = is a binary binding operator: it takes a left hand
operand, the variable (a name, for the sake of simplicity) and a right
hand operand (a value) and binds the value to the name.
> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.
Marko has some idiosyncratic beliefs about Python (and apparently other
languages as well) that are difficult to justify.
Especially in this case. Anyone who understands lambda calculus is
unlikely to be confused by Python using the same terms to mean something
*almost identical* to what they mean in lambda calculus. (The only
difference I can see is that lambda calculus treats variables as abstract
mathematical entities, while Python and other programming languages
vivify them and give them a concrete implementation.)
If one in ten thousand programmers are even aware of the existence of
lambda calculus, I would be surprised. To give up using perfectly good,
accurate terminology in favour of worse, less accurate terminology in
order to avoid unlikely and transient confusion among a minuscule subset
of programmers seems a poor tradeoff to me.
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
More information about the Python-list