Key ideas in depth: Running python files

A couple of things that are worth mentioning, in way of variables.

The first is that it is worth avoid starting variables with an underscore for now, as it has special meanings.

Double underscores are often used in Python to obfuscate variable and function names so they aren't accidentally reused. An example is the so called "dunder" notation, which puts important Python system variables and functions in the form __name__. Another example is so-called "name mangling", which we'll see when we look at classes later in the course.

Even a single underscore has specific meanings in some uses. You'll see that some people use a single underscore as a throwaway variable...

_ = 10 * 2
answer = _ * 5


...however, avoid it: in the REPL shell it holds the last evaluation so uses are easily confused:

>>> 2 + 2
4
>>> a = _
>>> a
4

The second thing is to say a bit more about hardwiring values. In general, you want to remove as many hardwired values as possible from programs, as each makes the program slightly less flexible. In the next part we'll see, for example, how you can pass values into your code from the command line. However, there will be occasions when hardwiring is definitely the answer.

The first is during development. If you haven't got data yet, for example, you might want to hardwire in some synthetic values. We'll see in the next part how to generate quite large amounts of synthetic data.

The second is in replacement for things you just can externalise, or there's no need to externalise. In general, when you start out building a solution, it can look like this:

circumference = 2 * 3.14 * 10

Sometimes it will stay like this, and other times, for example after we've found a function that gives us pi, and have written another to ask the user to input a radius, may change this to:

circumference = 2 * math.PI * get_radius_from_user()

By and large, it is worth building something general that works, using hardwiring, and then sort out the detail if it is needed; at least that way you'll have the generalities working if you run out of time. Working to generalities is sometimes called "abstraction", and it is a common theme. We'll see it when we look at how we construct objects, later in the course, but it is also a critical idea in modelling social and environmental systems, where we build general models first and only build in detail where we need it and have the data.