Why don't Python and Ruby make a distinction between declaring and assigning a value to variables?

Question

Two of the most popular dynamically typed scripting languages, Python and Ruby, do not make a distinction in syntax between the declaration of a variable and assignation of a value to it.

That is in both languages, declaring a variable n and assigning a value to it would look like so:

n = 10

And assigning a new value to the variable later on would look just the same.

This creates two major problems:

1. A typo in a variable's name when changing it's value would create a new variable and cause bugs.

2. It makes the intentions of the code less clear. Hard to know where a variable is first declared and used, might make the code more confusing.

What I don't understand is why these languages don't have a var keyword to use on declaration, to make a distinction between a declaration and an assignment. This doesn't make the language any less dynamically typed, and I see no drawbacks.

What is the advantage of not having to explicitly define a variable?

Answer 1

As a user rather (than designer) of Python there are three reasons I'm happy with this decisions:

Chiefly, it reads better. Of course I have to consciously decide to introduce a new variable when writing, but code is read far more often than it is written. A lot of code is simple in the sense that control flow and nesting has no influence on the meaning and existence of variables. When I read

it = Snark()
message = "A letter, not signed"
if random.random() > 0.5:
    hunt(it)
    message += " (by the Knave)"
return [it, message]

then I usually don't really care which (if any) mention of a name first introduces it, I just care that it's there and what happens to it.

Note that a significant body of pseudo code uses the same convention (no declaration, implicit introduction via assignment), and Python is often described as executable pseudo code, only half-jokingly. Four extra characters for every local variable does, to my spoiled eyes, feel like significant clutter in the context of Python, especially when it doesn't feel like it adds any value (see below); this would be lessened by a := operator as in Go.

Second, I have yet to encounter a typo bug (due to this specific feature) that didn't also show itself in another clear manner. Maybe I'll change my mind in a few more years when I've encountered some bugs of this kind, but so far it's way, way down on my list of things that cause bugs. There's a fair number of questions about UnboundLocalError and it's a bit tricky to explain to beginners, but the frequency and popularity of those questions, compared to other gotchas (mutable default parameters, reference semantics, class vs. instance variables) indicates it's a rare problem.

Finally, the intent thing... sorry but I can't really understand this one. When reading and writing Python, it's always perfectly clear: What you assign to is intended as a local, unless loudly and explicitly declared otherwise. No question about it. Moreover, since (at least in Python) a variable is either local for the entire function or not at all, you can't have tricky code that uses a local variable in one branch and a global one in another. You see a name being assigned to? You instantly know it was always local from the beginning. Well, unless the code is broken in a very special way (and will throw the dreaded UnboundLocalError at run time, when entering those cases).

Answer 2

It's not that defining a variable is the same as assigning to it -- it's that the variables are not defined at all. It's called Dynamic Typing.

You can't have a dynamically typed language that lets you define a variable, because that's what dynamic typing is.

The decision to do this completely changes the nature of the parser, and results in a completely different sort of language. The principal difference to the end-user is usually that, when defining a function, your parameters turn out to be any type at all ("duck typing"), which is both a blessing, in that it makes your code much simpler, and a curse, in that it allows for a multitude of new ways that your code can fail.

I'm no compiler expert but I think it's also true that Dynamic Typing has major implications for the flavour of OOP you get in a language.