memory-graph 0.3.3__tar.gz → 0.3.5__tar.gz

{memory_graph-0.3.3/memory_graph.egg-info → memory_graph-0.3.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: memory_graph
-Version: 0.3.3
+Version: 0.3.5
 Summary: Draws a graph of your data to analyze its structure.
 Home-page: https://github.com/bterwijn/memory_graph
 Author: Bas Terwijn
@@ -124,19 +124,19 @@ ___
 The [Python Data Model](https://docs.python.org/3/reference/datamodel.html) makes a distiction between immutable and mutable types:
 
 * **immutable**: bool, int, float, complex, str, tuple, bytes, frozenset
-* **mutable**: list, dict, set, class, ... (all other types)
+* **mutable**: list, dict, set, class, ... (most other types)
 
 
 ### Immutable Type ###
-In the code below variable `a` and `b` both reference the same `int` value 10. An `int` is an immutable type and therefore when we change variable `a` its value can **not** be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+In the code below variable `a` and `b` both reference the same tuple value (4, 3, 2). A tuple is an immutable type and therefore when we change variable `a` its value can not be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+
 ```python
 import memory_graph
-memory_graph.config.not_node_types.remove(int) # show nodes for ints
 
-a = 10
+a = (4, 3, 2)
 b = a
 memory_graph.render(locals(), 'immutable1.png')
-a += 1
+a += (1,)
 memory_graph.render(locals(), 'immutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable2.png) |
@@ -153,7 +153,7 @@ import memory_graph
 a = [4, 3, 2]
 b = a
 memory_graph.render(locals(), 'mutable1.png')
-a.append(1)
+a += [1] # equivalent to:  a.append(1)
 memory_graph.render(locals(), 'mutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable2.png) |
@@ -161,7 +161,7 @@ memory_graph.render(locals(), 'mutable2.png')
 | mutable1.png | mutable2.png |
 
 
-Python makes this distiction between mutable and immutable types because a value of a mutable type generally could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a changable immutable type generally is small and therefore fast to copy.
+Python makes this distiction between mutable and immutable types because a value of a mutable type could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a immutable type generally is small and therefore fast to copy.
 
 
 ### Copying ###
@@ -263,19 +263,19 @@ as a *watchpoint* in a debugger tool and open the "my_debug_graph.pdf" output fi
 
 
 ## 3. Call Stack ##
-Function ```memory_graph.get_call_stack()``` returns the full call stack that holds for each called function all the local variables. This enables us to visualize the local variables of each of the called functions simultaneously. This helps to visualize if variables of different called functions share any data between them. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds one to change each of its arguments.
+The function `memory_graph.get_call_stack()` returns the complete call stack, including all local variables for each function in the stack. This allows us to simultaneously visualize the local variables of all the called functions. By doing so, we can identify whether any local variables from different functions in the call stack share data with one another. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds 1 to each of its arguments.
 
 ```python
 import memory_graph
 
 def add_one(a, b, c):
-    a += 1
-    b.append(1)
-    c.append(1)
+    a += [1]
+    b += (1,)
+    c += [1]
     memory_graph.show(memory_graph.get_call_stack())
 
-a = 10
-b = [4, 3, 2]
+a = [4, 3, 2]
+b = (4, 3, 2)
 c = [4, 3, 2]
 
 add_one(a, b, c.copy())
@@ -283,13 +283,16 @@ print(f"a:{a} b:{b} c:{c}")
 ```
 ![add_one.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/add_one.png)
 
-As `a` is of immutable type 'int' and as we call the function with a copy of `c`, only `b` is shared so only `b` is changed in the calling stack frame as reflected in the printed output:
+In the printed output only `a` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:[4, 3, 2, 1] b:(4, 3, 2) c:[4, 3, 2]
 ```
 
+This is because `b` is of immutable type 'tuple' so its value gets copied automatically when it is changed. And because the function is called with a copy of `c`, its original value is not changed by the function. The value of variable `a` is the only value of mutable type that is shared between the root stack frame **0: \<module>** and the **1: add_one** stack frame of the function so only that variable is affected as a result of the function call. The other changes remain confined to the local variables of the ```add_one()``` function.
+
+
 ### Recursion ###
-The call stack also helps to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
+The call stack can be used to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
 
 ```python
 import memory_graph
@@ -308,7 +311,7 @@ print(factorial(3))
 
 and the final result is: 1 x 2 x 3 = 6
 
-### Call Stack in Watchpoint ###
+### Call Stack in Watchpoint Context ###
 The ```memory_graph.get_call_stack()``` doesn't work well in a watchpoint context in most debuggers because debuggers introduce additional stack frames that cause problems. Use these alternative functions for various debuggers to filter out these problematic stack frames:
 
 | debugger | function to get the call stack |

{memory_graph-0.3.3 → memory_graph-0.3.5}/README.md

@@ -105,19 +105,19 @@ ___
 The [Python Data Model](https://docs.python.org/3/reference/datamodel.html) makes a distiction between immutable and mutable types:
 
 * **immutable**: bool, int, float, complex, str, tuple, bytes, frozenset
-* **mutable**: list, dict, set, class, ... (all other types)
+* **mutable**: list, dict, set, class, ... (most other types)
 
 
 ### Immutable Type ###
-In the code below variable `a` and `b` both reference the same `int` value 10. An `int` is an immutable type and therefore when we change variable `a` its value can **not** be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+In the code below variable `a` and `b` both reference the same tuple value (4, 3, 2). A tuple is an immutable type and therefore when we change variable `a` its value can not be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+
 ```python
 import memory_graph
-memory_graph.config.not_node_types.remove(int) # show nodes for ints
 
-a = 10
+a = (4, 3, 2)
 b = a
 memory_graph.render(locals(), 'immutable1.png')
-a += 1
+a += (1,)
 memory_graph.render(locals(), 'immutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable2.png) |
@@ -134,7 +134,7 @@ import memory_graph
 a = [4, 3, 2]
 b = a
 memory_graph.render(locals(), 'mutable1.png')
-a.append(1)
+a += [1] # equivalent to:  a.append(1)
 memory_graph.render(locals(), 'mutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable2.png) |
@@ -142,7 +142,7 @@ memory_graph.render(locals(), 'mutable2.png')
 | mutable1.png | mutable2.png |
 
 
-Python makes this distiction between mutable and immutable types because a value of a mutable type generally could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a changable immutable type generally is small and therefore fast to copy.
+Python makes this distiction between mutable and immutable types because a value of a mutable type could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a immutable type generally is small and therefore fast to copy.
 
 
 ### Copying ###
@@ -244,19 +244,19 @@ as a *watchpoint* in a debugger tool and open the "my_debug_graph.pdf" output fi
 
 
 ## 3. Call Stack ##
-Function ```memory_graph.get_call_stack()``` returns the full call stack that holds for each called function all the local variables. This enables us to visualize the local variables of each of the called functions simultaneously. This helps to visualize if variables of different called functions share any data between them. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds one to change each of its arguments.
+The function `memory_graph.get_call_stack()` returns the complete call stack, including all local variables for each function in the stack. This allows us to simultaneously visualize the local variables of all the called functions. By doing so, we can identify whether any local variables from different functions in the call stack share data with one another. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds 1 to each of its arguments.
 
 ```python
 import memory_graph
 
 def add_one(a, b, c):
-    a += 1
-    b.append(1)
-    c.append(1)
+    a += [1]
+    b += (1,)
+    c += [1]
     memory_graph.show(memory_graph.get_call_stack())
 
-a = 10
-b = [4, 3, 2]
+a = [4, 3, 2]
+b = (4, 3, 2)
 c = [4, 3, 2]
 
 add_one(a, b, c.copy())
@@ -264,13 +264,16 @@ print(f"a:{a} b:{b} c:{c}")
 ```
 ![add_one.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/add_one.png)
 
-As `a` is of immutable type 'int' and as we call the function with a copy of `c`, only `b` is shared so only `b` is changed in the calling stack frame as reflected in the printed output:
+In the printed output only `a` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:[4, 3, 2, 1] b:(4, 3, 2) c:[4, 3, 2]
 ```
 
+This is because `b` is of immutable type 'tuple' so its value gets copied automatically when it is changed. And because the function is called with a copy of `c`, its original value is not changed by the function. The value of variable `a` is the only value of mutable type that is shared between the root stack frame **0: \<module>** and the **1: add_one** stack frame of the function so only that variable is affected as a result of the function call. The other changes remain confined to the local variables of the ```add_one()``` function.
+
+
 ### Recursion ###
-The call stack also helps to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
+The call stack can be used to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
 
 ```python
 import memory_graph
@@ -289,7 +292,7 @@ print(factorial(3))
 
 and the final result is: 1 x 2 x 3 = 6
 
-### Call Stack in Watchpoint ###
+### Call Stack in Watchpoint Context ###
 The ```memory_graph.get_call_stack()``` doesn't work well in a watchpoint context in most debuggers because debuggers introduce additional stack frames that cause problems. Use these alternative functions for various debuggers to filter out these problematic stack frames:
 
 | debugger | function to get the call stack |

{memory_graph-0.3.3 → memory_graph-0.3.5}/memory_graph/__init__.py

@@ -9,7 +9,7 @@ import sys
 
 import graphviz
 
-__version__ = "0.3.03"
+__version__ = "0.3.05"
 __author__ = 'Bas Terwijn'
 
 log_file=sys.stdout

{memory_graph-0.3.3 → memory_graph-0.3.5/memory_graph.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: memory_graph
-Version: 0.3.3
+Version: 0.3.5
 Summary: Draws a graph of your data to analyze its structure.
 Home-page: https://github.com/bterwijn/memory_graph
 Author: Bas Terwijn
@@ -124,19 +124,19 @@ ___
 The [Python Data Model](https://docs.python.org/3/reference/datamodel.html) makes a distiction between immutable and mutable types:
 
 * **immutable**: bool, int, float, complex, str, tuple, bytes, frozenset
-* **mutable**: list, dict, set, class, ... (all other types)
+* **mutable**: list, dict, set, class, ... (most other types)
 
 
 ### Immutable Type ###
-In the code below variable `a` and `b` both reference the same `int` value 10. An `int` is an immutable type and therefore when we change variable `a` its value can **not** be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+In the code below variable `a` and `b` both reference the same tuple value (4, 3, 2). A tuple is an immutable type and therefore when we change variable `a` its value can not be mutated in place, and thus a copy is made and `a` and `b` reference a different value afterwards.
+
 ```python
 import memory_graph
-memory_graph.config.not_node_types.remove(int) # show nodes for ints
 
-a = 10
+a = (4, 3, 2)
 b = a
 memory_graph.render(locals(), 'immutable1.png')
-a += 1
+a += (1,)
 memory_graph.render(locals(), 'immutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/immutable2.png) |
@@ -153,7 +153,7 @@ import memory_graph
 a = [4, 3, 2]
 b = a
 memory_graph.render(locals(), 'mutable1.png')
-a.append(1)
+a += [1] # equivalent to:  a.append(1)
 memory_graph.render(locals(), 'mutable2.png')
 ```
 | ![mutable1.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable1.png) | ![mutable2.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/mutable2.png) |
@@ -161,7 +161,7 @@ memory_graph.render(locals(), 'mutable2.png')
 | mutable1.png | mutable2.png |
 
 
-Python makes this distiction between mutable and immutable types because a value of a mutable type generally could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a changable immutable type generally is small and therefore fast to copy.
+Python makes this distiction between mutable and immutable types because a value of a mutable type could be large and therefore it would be slow to make a copy each time we change it. On the other hand, a value of a immutable type generally is small and therefore fast to copy.
 
 
 ### Copying ###
@@ -263,19 +263,19 @@ as a *watchpoint* in a debugger tool and open the "my_debug_graph.pdf" output fi
 
 
 ## 3. Call Stack ##
-Function ```memory_graph.get_call_stack()``` returns the full call stack that holds for each called function all the local variables. This enables us to visualize the local variables of each of the called functions simultaneously. This helps to visualize if variables of different called functions share any data between them. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds one to change each of its arguments.
+The function `memory_graph.get_call_stack()` returns the complete call stack, including all local variables for each function in the stack. This allows us to simultaneously visualize the local variables of all the called functions. By doing so, we can identify whether any local variables from different functions in the call stack share data with one another. Here for example we call function ```add_one()``` with arguments ```a, b, c``` that adds 1 to each of its arguments.
 
 ```python
 import memory_graph
 
 def add_one(a, b, c):
-    a += 1
-    b.append(1)
-    c.append(1)
+    a += [1]
+    b += (1,)
+    c += [1]
     memory_graph.show(memory_graph.get_call_stack())
 
-a = 10
-b = [4, 3, 2]
+a = [4, 3, 2]
+b = (4, 3, 2)
 c = [4, 3, 2]
 
 add_one(a, b, c.copy())
@@ -283,13 +283,16 @@ print(f"a:{a} b:{b} c:{c}")
 ```
 ![add_one.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/add_one.png)
 
-As `a` is of immutable type 'int' and as we call the function with a copy of `c`, only `b` is shared so only `b` is changed in the calling stack frame as reflected in the printed output:
+In the printed output only `a` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:[4, 3, 2, 1] b:(4, 3, 2) c:[4, 3, 2]
 ```
 
+This is because `b` is of immutable type 'tuple' so its value gets copied automatically when it is changed. And because the function is called with a copy of `c`, its original value is not changed by the function. The value of variable `a` is the only value of mutable type that is shared between the root stack frame **0: \<module>** and the **1: add_one** stack frame of the function so only that variable is affected as a result of the function call. The other changes remain confined to the local variables of the ```add_one()``` function.
+
+
 ### Recursion ###
-The call stack also helps to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
+The call stack can be used to visualize how recursion works. Here we show each step of how recursively ```factorial(3)``` is computed:
 
 ```python
 import memory_graph
@@ -308,7 +311,7 @@ print(factorial(3))
 
 and the final result is: 1 x 2 x 3 = 6
 
-### Call Stack in Watchpoint ###
+### Call Stack in Watchpoint Context ###
 The ```memory_graph.get_call_stack()``` doesn't work well in a watchpoint context in most debuggers because debuggers introduce additional stack frames that cause problems. Use these alternative functions for various debuggers to filter out these problematic stack frames:
 
 | debugger | function to get the call stack |

{memory_graph-0.3.3 → memory_graph-0.3.5}/setup.py

@@ -7,7 +7,7 @@ long_description_from_readme = (this_directory / "README.md").read_text()
 
 setup(
     name = 'memory_graph',
-    version = '0.3.03',
+    version = '0.3.05',
     description = 'Draws a graph of your data to analyze its structure.',
     long_description = long_description_from_readme,
     long_description_content_type = 'text/markdown',