从最开始的变量开始思考：
在python中，如果要使用一个变量，不需要提前进行声明，只需要在用的时候，给这个变量赋值即可 (这个和C语言等静态类型语言不同，和python为动态类型有关)。
举第一个例子：
a = 1
这是一个简单的赋值语句，整数 1 为一个对象，a 是一个引用，利用赋值语句，引用a指向了对象1；这边形象比喻一下：这个过程就相当于“放风筝”，变量a就是你手里面的“线”，python就跟那根“线”一样，通过引用来接触和拴住天空中的风筝——对象。
你可以通过python的内置函数 id() 来查看对象的身份(identity)，这个所谓的身份其实就是 对象 的内存地址：
注：
python一切皆对象的理念，所以函数也是一个对象，因此可以使用 id() 函数的__doc__方法来查看这个函数的具体描述。
先举个例子：
第一个语句中， 2是储存在内存中的一个整数对象，通过赋值 引用a 指向了 对象 1；
第二个语句中，内存中建立了一个字符串对象‘banana’，通过赋值 将 引用a 指向了 ‘banana’，同时，对象1不在有引用指向它，它会被python的内存处理机制给当我垃圾回收，释放内存。
再举一个例子：
第一个语句中， 2是储存在内存中的一个整数对象，通过赋值 引用a 指向了 对象 1；
第二个语句中，内存中建立了一个字符串对象‘banana’，通过赋值 将 引用a 指向了 ‘banana’，同时，对象1不在有引用指向它，它会被python的内存处理机制给当我垃圾回收，释放内存。
再来一个例子：
通过函数查看 变量a 和 变量b的引用情况：
在这里可以看到 这俩个引用 指向了同一个 对象，这是为什么呢？ 这个跟python的内存机制有关系，因为对于语言来说，频繁的进行对象的销毁和建立，特别浪费性能。所以在Python中，整数和短小的字符，Python都会缓存这些对象，以便重复使用。
然后再看看这个例子：
1. a = 4
2. b = a（这里就是让引用b指向引用a指向的那个对象）
3. a = a + 2
通过函数查看引用情况：
当执行到第2步的时候，查看一下 a 和 b 的引用：
可以看到 a 和 b 都指向了 整数对象 4
接下来指向第3步：
可以看到 a 的引用改变了，但是 b 的引用未发生改变；a，b指向不同的对象； 第3句对 a 进行了重新赋值，让它指向了新的 对象6；即使是多个引用指向同一个对象，如果一个引用值发生变化，那么实际上是让这个引用指向一个新的引用，并不影响其他的引用的指向。从效果上看，就是各个引用各自独立，互不影响。
还有一个必须要看的例子:
所以，每次列表实际上都是添加同一个对象。
copy.copy() 浅拷贝。只拷贝父对象，不会拷贝对象的内部的子对象。
那么，copy.copy()和copy.deepcopy()有什么区别呢?
copy.deepcopy() 深拷贝 拷贝对象及其子对象。
最后一个例子：
（这个栗子会涉及到 python中的 可变数据类型 和 不可变数据类型）：
开始这个栗子之前，请记得注意到 第四个栗子的不同之处。
1. L1 = [1, 2, 3]
2. L2 = L1
3. L1[0] = 10
通过函数查看引用情况：
当执行第1步 和 第二步 的时候，查看一下 L1 和 L2 的引用情况：
此时 L1 和 L2 的引用相同，都是指向 [1,2,3]这个列表对象。
接下来，继续执行第3步：
同样的跟第四个栗子那样，修改了其中一个对象的值，但是可以发现 结果 并不与 第四个栗子那样， 在本次实验中，L1 和 L2 的引用没有发生任何变化，但是 列表对象[1,2,3] 的值 变成了 [10,2,3]（列表对象改变了）
在该情况下，我们不再对L1这一引用赋值，而是对L1所指向的表的元素赋值。结果是，L2也同时发生变化。
原因何在呢？因为L1，L2的指向没有发生变化，依然指向那个表。表实际上是包含了多个引用的对象（每个引用是一个元素，比如L1[0]，L1[1]..., 每个引用指向一个对象，比如1,2,3), 。而L1[0] = 10这一赋值操作，并不是改变L1的指向，而是对L1[0], 也就是表对象的一部份(一个元素)，进行操作，所以所有指向该对象的引用都受到影响。
（与之形成对比的是，我们之前的赋值操作都没有对对象自身发生作用，只是改变引用指向。）
列表可以通过引用其元素，改变对象自身(in-place change)。这种对象类型，称为可变数据对象(mutable object)，词典也是这样的数据类型。
而像之前的数字和字符串，不能改变对象本身，只能改变引用的指向，称为不可变数据对象(immutable object)。
我们之前学的元组(tuple)，尽管可以调用引用元素，但不可以赋值，因此不能改变对象自身，所以也算是immutable object.
