Variables and data types

What exactly is a variable, and how do you make one?

A variable is a name you give a value. That is all. In Python making one is a single line and needs no extra keyword:

city = "Tehran"
visits = 1200

Now wherever you write city, Python puts that string there. The equals sign has no mathematical meaning here either; it does not say these two are equal, it says attach this name to that value. Which is why this line is perfectly sensible in code and meaningless in mathematics:

visits = visits + 1

The usual "a variable is a box" comparison helps up to a point and then misleads you. More precisely: a variable is a label stuck onto a value. Two labels can sit on one value, and that is what builds a real trap in section five of this lesson.

Three naming rules that make life easier from day one. Start the name with a letter and put no space in it; use an underscore instead, as in total_price. Do not shorten a name to type less, because three weeks later tp is a riddle even to you. And write names in English even when the program is Persian, because the rest of the code you will read is written that way.

The five types that do the everyday work

The figure at the top of this page arranges five types around one centre, and that centre is the value itself. Other languages have more types, but for your first months these five do nearly all the work.

price = 120000
rate = 1.09
name = "Sara"
is_paid = True
items = ["pen", "book"]
user = {"name": "Sara", "city": "Tehran"}

Whole numbers and decimals are two separate types, and that separation earns its keep later. A string is text and always sits in quotes. A boolean has only two values, True and False, and it is the heart of every condition. A list holds several values in order and you reach them by number. And a dictionary keeps values by key rather than by number, so instead of "the third one" you say "city".

print(items[0])
print(user["city"])

Counting starts at zero, so items[0] is the first member. That is one of the things that annoys you a few times in the first month and then becomes ordinary.

If you do not know what you are holding, ask Python itself. The type function answers, and it is our main tool throughout this lesson:

print(type(price))
print(type(name))

Why does age plus one raise an error?

This is everybody first real meeting with data types, and it almost always starts with input. Run this:

age = "17"
print(type(age))
print(age + 1)

The second line prints <class 'str'> and the third knocks the program over. Here is the exact message, the one we got when we ran it:

TypeError: can only concatenate str (not "int") to str

Translated: the plus sign between two strings means joining and between two numbers means adding, but between a string and a number it means nothing, and Python does not guess which one you wanted. The fix is one word:

age = "17"
print(int(age) + 1)

The output is 18. int turns a string into a whole number, float into a decimal, and str goes the other way. Three functions, and ninety per cent of conversion work is done with them.

One point that pays off later in conditions: in Python a string and a number are not equal even when they look alike. The expression "7" == 7 evaluates to False. If you ever have a condition you were sure should be true and it was not, check this first.

And a warning about conversion: int("abc") raises an error, and that is correct behaviour. If you find somebody who silenced that error with an empty try, the program no longer crashes but from then on it quietly produces wrong data, which is worse.

Why does adding two decimals not give what you expect?

Run this and look at the output:

print(0.1 + 0.2)

It prints 0.30000000000000004. This is not a Python bug; JavaScript, PHP and nearly every other language do the same. The reason is that a computer keeps decimals in base two, and some fractions do not terminate in base two, exactly as one third does not terminate in base ten. Python own documentation gives a whole page to it.

For display the fix is simple:

print(round(0.1 + 0.2, 2))

which prints 0.3. But that only fixes the display, and it is not enough for money.

Learn the money rule here, because the most expensive bugs a new developer writes are of this family: do not keep money in a decimal. You have two correct routes. One is to keep everything in the smallest unit as a whole number, so integer rials or tomans rather than fractional ones. The other is the decimal module, which exists for exactly this.

We took the first route ourselves and it can be seen. The prices on this site are converted from dollars to tomans, and in that same line the result is rounded to the nearest thousand tomans and then cast to a whole number. That is why no price on this site has a decimal part; not because it looks tidier, but because a fraction of a toman does not exist in the world, and any number that carries one shows itself in a sum sooner or later.

List or dictionary: which one goes where?

The rule in one sentence: if the things are of one kind and their order matters, a list; if each one has a name and you call it by that name, a dictionary. The figure below puts that in two columns, and neither column is better than the other.

But there is a trap in lists that surprises people more than anything else in this lesson. Remember that a variable is a label and not a box? This is what follows from it:

a = [1, 2]
b = a
b.append(3)
print(a)

The output is [1, 2, 3], not [1, 2]. We added something to b and a changed too, because both names are stuck onto one list and no second list was ever made. If you really want a separate copy, you have to say so:

c = a.copy()
c.append(4)
print(a, c)

which prints [1, 2, 3] [1, 2, 3, 4]. Now they are two separate things.

Why does this matter? Because in larger programs you pass a list to a function, the function changes it, and you believe your own copy is untouched. It raises no error and nothing falls over; your data just quietly changes. Strings and numbers do not behave this way, which is why the trap comes only for lists and dictionaries.

When the type is wrong and no error appears

Up to here every type error made a noise. Now for the family that makes none, and is more expensive for exactly that reason. Two examples from this site, both checkable in our own code.

The first. Every piece of text in this learning section has to be a four language array, that is a data structure with four keys. Once, in the AI section of this site, a plain string was written instead of an array. Nothing raised an error; a string is a value too and it prints. The result was that the English page printed Persian text. The mistake was not in the value, it was in the type. Now the validator of this section checks exactly that before publication, and when it sees a string it says it must be a four language array and reports the type it got.

The second is more instructive. The theme of this site turns numeric table columns into bars, and to do that it has to read a number written in the text. The first rule was that a comma is a thousands separator. On the Turkish page, "2,6 MB" became twenty six and "80,6 per cent" became eight hundred and six, and a bar was drawn eight times longer than what the page itself said. The cause was our assumption: Turkish uses the dot for thousands and the comma for decimals, exactly the other way round from Persian and English.

The solution finally chosen does not ask for the language; it looks at the size of the groups. A group of exactly three digits is thousands and anything else is a decimal, with one exception: a number starting with zero is always a decimal. What matters here is that neither of those two bugs raised an error. The program ran happily and printed a wrong number.

The lesson we took from both, and pass on: check the type at the boundary, meaning the place where data enters the program. User input, a file you read, an answer you get from a service. If you do not control the type there, wrong data travels deep into the program, and by then nobody can tell where it came from.