As in all programming languages, values can be assigned to variables in Python. But a variable is just a name for an object: thus, in an assignment, a variable acquires an object's type along with its value. If a variable is reassigned to another object of a different type, it then acquires that type. This is because Python uses dynamic typing. There is no need to declare the types of variables, since a variable (i.e., a name) can be bound to any type of object.

Values of variables can be set with simple assignment statements such as:

Note that a list and a string were created in the last two statements. Python has no problem with creating these variables on the fly, even though you haven't declared their sizes in advance. In an assignment statement, the right-hand side of the assignment is first evaluated, and then attached to the variable name on the left-hand side.

Just as we don't have to declare the types of variables before assigning to them, we also don't have to declare the types of arguments in function declarations (which we will describe in more detail in subsequent pages). Whether or not an object is suitable as an input to a function only depends on what is requested of that object in that function, regardless of what type the object is. This is known as duck typing: if it walks like a duck, and it quacks like a duck, then it must be a duck (regardless of whatever you choose to call it). Consider these two function definitions:

In the first example, the only requests made of the arguments x and y are that they can be added together via the + operator. As long as two inputs can be added together (whatever that means in the context of those two objects), then they are valid inputs to the function f. In the second example, the only request made of the input object z is that we can call the function len on that object. len is a built-in Python function that returns the length of an object like a list, so any object whose length can be computed with this function is a valid input to the function g. In either case, if we passed in objects that did not support the requested operations, a runtime error (exception) would be generated. These are both examples of duck typing.

We can find out the type of any object with the use of the built-in function type: When we call this function on a variable, what we actually get is its class. In Python 3, this appears as:

In Python 2, the outputs returned by the expressions above appear slightly differently, such as and . This difference is due to the unification of types and classes under new-style classes in Python 3.

Many basic objects in Python, like strings and numbers, are immutable, meaning once an object is created, it cannot be changed. (Technically, numbers and strings are literals. The number 3 can't be changed because it literally has that value. The string "apple" has the value "apple", and the value of that literal cannot be changed to "orange".) But variables can be assigned new values, even if that means overwriting the old values assigned to them. What's happening below is that an expression on the right side of an assignment is evaluated, and the result of that expression is assigned to a variable on the left side (which happens to have the same name as a variable on the right):

Variable names follow the rules you would expect from other more traditional languages. Specifically, variable names must start with either a letter or an underscore (they cannot start with a number), followed by any combination of numbers, letters, or other characters. Variables are also case sensitive, so “variable” and “Variable” would be different variables.

A few notes for those of you used to working with variables in other programming languages:

  • In Python 3, there is no long type; there is only an int type for integers, and they can be arbitrarily large. (In Python 2, there was a long type for sufficiently long integers, and their textual representation included a trailing "L").
  • In Python 3, all text strings are Unicode, not ASCII. (If you don't know what this means, it probably isn't a problem for you yet, so don't worry about it.)
 
©  |   Cornell University    |   Center for Advanced Computing    |   Copyright Statement    |   Inclusivity Statement