mathdatech/python_reference
1
0
Fork 0
mirror of https://github.com/rasbt/python_reference.git synced 2025-02-17 13:58:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

immutable tuple upd.

Browse Source
This commit is contained in:
rasbt 2014-04-15 21:21:30 -04:00
parent 40d7d7b897
commit f3844ea83b
2 changed files with 126 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
.ipynb_checkpoints/not_so_obvious_python_stuff-checkpoint.ipynb
View File

@ -1,7 +1,7 @@
{
"metadata": {
"name": "",
"signature": "sha256:d6f2ef62f297b01c2d33ebe34af91db1e402323086d1abc1c6827557351df297"
"signature": "sha256:29a120258e2d108ed5eace08e071ad866ae379b4f24fde804401ee858a2090fb"
},
"nbformat": 3,
"nbformat_minor": 0,
@ -988,6 +988,68 @@
"If we try to extend the list via `+=` *\"then the statement executes STORE_SUBSCR, which calls the C function PyObject_SetItem, which checks if the object supports item assignment. In our case the object is a tuple, so PyObject_SetItem throws the TypeError. Mystery solved.\"*"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"#### One more note about the `immutable` status of tuples. Tuples are famous for being immutable. However, how comes that this code works?"
]
},
{
"cell_type": "code",
"collapsed": false,
"input": [
"my_tup = (1,)\n",
"my_tup += (4,)\n",
"my_tup = my_tup + (5,)\n",
"print(my_tup)"
],
"language": "python",
"metadata": {},
"outputs": [
{
"output_type": "stream",
"stream": "stdout",
"text": [
"(1, 4, 5)\n"
]
}
],
"prompt_number": 6
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"What happens \"behind\" the curtains is that the tuple is not modified, but every time a new object is generated, which will inherit the old \"name tag\":"
]
},
{
"cell_type": "code",
"collapsed": false,
"input": [
"my_tup = (1,)\n",
"print(id(my_tup))\n",
"my_tup += (4,)\n",
"print(id(my_tup))\n",
"my_tup = my_tup + (5,)\n",
"print(id(my_tup))"
],
"language": "python",
"metadata": {},
"outputs": [
{
"output_type": "stream",
"stream": "stdout",
"text": [
"4337381840\n",
"4357415496\n",
"4357289952\n"
]
}
],
"prompt_number": 8
},
{
"cell_type": "markdown",
"metadata": {},

64
not_so_obvious_python_stuff.ipynb
View File

@ -1,7 +1,7 @@
{
"metadata": {
"name": "",
"signature": "sha256:d6f2ef62f297b01c2d33ebe34af91db1e402323086d1abc1c6827557351df297"
"signature": "sha256:29a120258e2d108ed5eace08e071ad866ae379b4f24fde804401ee858a2090fb"
},
"nbformat": 3,
"nbformat_minor": 0,
@ -988,6 +988,68 @@
"If we try to extend the list via `+=` *\"then the statement executes STORE_SUBSCR, which calls the C function PyObject_SetItem, which checks if the object supports item assignment. In our case the object is a tuple, so PyObject_SetItem throws the TypeError. Mystery solved.\"*"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"#### One more note about the `immutable` status of tuples. Tuples are famous for being immutable. However, how comes that this code works?"
]
},
{
"cell_type": "code",
"collapsed": false,
"input": [
"my_tup = (1,)\n",
"my_tup += (4,)\n",
"my_tup = my_tup + (5,)\n",
"print(my_tup)"
],
"language": "python",
"metadata": {},
"outputs": [
{
"output_type": "stream",
"stream": "stdout",
"text": [
"(1, 4, 5)\n"
]
}
],
"prompt_number": 6
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"What happens \"behind\" the curtains is that the tuple is not modified, but every time a new object is generated, which will inherit the old \"name tag\":"
]
},
{
"cell_type": "code",
"collapsed": false,
"input": [
"my_tup = (1,)\n",
"print(id(my_tup))\n",
"my_tup += (4,)\n",
"print(id(my_tup))\n",
"my_tup = my_tup + (5,)\n",
"print(id(my_tup))"
],
"language": "python",
"metadata": {},
"outputs": [
{
"output_type": "stream",
"stream": "stdout",
"text": [
"4337381840\n",
"4357415496\n",
"4357289952\n"
]
}
],
"prompt_number": 8
},
{
"cell_type": "markdown",
"metadata": {},