memory-graph 0.3.2__tar.gz → 0.3.4__tar.gz

{memory_graph-0.3.2 → memory_graph-0.3.4}/PKG-INFO

@@ -1,12 +1,11 @@
 Metadata-Version: 2.1
 Name: memory_graph
-Version: 0.3.2
+Version: 0.3.4
 Summary: Draws a graph of your data to analyze its structure.
 Home-page: https://github.com/bterwijn/memory_graph
 Author: Bas Terwijn
 Author-email: bterwijn@gmail.com
 License: BSD 2-clause
-Platform: UNKNOWN
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Education
 Classifier: Intended Audience :: Developers
@@ -16,6 +15,7 @@ Classifier: Topic :: Education
 Classifier: Topic :: Software Development :: Debuggers
 Description-Content-Type: text/markdown
 License-File: LICENSE.txt
+Requires-Dist: graphviz
 
 # Installation #
 Install (or upgrade) `memory_graph` using pip:
@@ -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.no_reference_types.pop(int, None) # show references to 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) |
@@ -263,33 +263,36 @@ 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
+a = (4, 3, 2)
 b = [4, 3, 2]
 c = [4, 3, 2]
 
-add_one(a, b, c.copy())
+add_one(a, b.copy(), c)
 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 `c` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:(4, 3, 2) b:[4, 3, 2] c:[4, 3, 2, 1]
 ```
 
+This is because `a` 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 `b`, its original value is not changed by the function. 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 is `c`, so only that values is changed as a result of the function call.
+
+
 ### 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 |
@@ -462,8 +465,8 @@ Different aspects of memory_graph can be configured. The default configuration i
 - ***memory_graph.config.max_string_length*** : int
   - The maximum length of strings shown in the graph. Longer strings will be truncated.
 
-- ***memory_graph.config.no_reference_types*** : dict
-  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node. It maps each type to a function that determines how it is visualized.
+- ***memory_graph.config.not_node_types*** : set
+  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node.
 
 - ***memory_graph.config.no_child_references_types*** : set
   - The set of key_value types that don't draw references to their direct childeren but have their children shown as elements of their node.
@@ -550,5 +553,3 @@ See for example [jupyter_example.ipynb](https://raw.githubusercontent.com/bterwi
 
 - When graph edges overlap it can be hard to distinguish them. Using an interactive graphviz viewer, such as [xdot](https://github.com/jrfonseca/xdot.py), on a '*.gv' DOT output file will help.
 
-
-

{memory_graph-0.3.2 → memory_graph-0.3.4}/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.no_reference_types.pop(int, None) # show references to 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) |
@@ -244,33 +244,36 @@ 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
+a = (4, 3, 2)
 b = [4, 3, 2]
 c = [4, 3, 2]
 
-add_one(a, b, c.copy())
+add_one(a, b.copy(), c)
 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 `c` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:(4, 3, 2) b:[4, 3, 2] c:[4, 3, 2, 1]
 ```
 
+This is because `a` 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 `b`, its original value is not changed by the function. 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 is `c`, so only that values is changed as a result of the function call.
+
+
 ### 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 |
@@ -443,8 +446,8 @@ Different aspects of memory_graph can be configured. The default configuration i
 - ***memory_graph.config.max_string_length*** : int
   - The maximum length of strings shown in the graph. Longer strings will be truncated.
 
-- ***memory_graph.config.no_reference_types*** : dict
-  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node. It maps each type to a function that determines how it is visualized.
+- ***memory_graph.config.not_node_types*** : set
+  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node.
 
 - ***memory_graph.config.no_child_references_types*** : set
   - The set of key_value types that don't draw references to their direct childeren but have their children shown as elements of their node.

{memory_graph-0.3.2 → memory_graph-0.3.4}/memory_graph/__init__.py

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

{memory_graph-0.3.2 → memory_graph-0.3.4}/memory_graph/extension_numpy.py

@@ -8,8 +8,8 @@ import numpy as np
 
 config.not_node_types |= {
     np.int8, np.int16, np.int32, np.int64, np.uint8, np.uint16, np.uint32, np.uint64, 
-    np.float16, np.float32, np.float64, np.float_, 
-    np.complex64, np.complex128, np.complex_, 
+    np.float16, np.float32, np.float64,
+    np.complex64, np.complex128,
     np.bool_, np.bytes_, np.str_, np.datetime64, np.timedelta64
 }
 

{memory_graph-0.3.2 → memory_graph-0.3.4}/memory_graph.egg-info/PKG-INFO

@@ -1,12 +1,11 @@
 Metadata-Version: 2.1
-Name: memory-graph
-Version: 0.3.2
+Name: memory_graph
+Version: 0.3.4
 Summary: Draws a graph of your data to analyze its structure.
 Home-page: https://github.com/bterwijn/memory_graph
 Author: Bas Terwijn
 Author-email: bterwijn@gmail.com
 License: BSD 2-clause
-Platform: UNKNOWN
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Education
 Classifier: Intended Audience :: Developers
@@ -16,6 +15,7 @@ Classifier: Topic :: Education
 Classifier: Topic :: Software Development :: Debuggers
 Description-Content-Type: text/markdown
 License-File: LICENSE.txt
+Requires-Dist: graphviz
 
 # Installation #
 Install (or upgrade) `memory_graph` using pip:
@@ -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.no_reference_types.pop(int, None) # show references to 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) |
@@ -263,33 +263,36 @@ 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
+a = (4, 3, 2)
 b = [4, 3, 2]
 c = [4, 3, 2]
 
-add_one(a, b, c.copy())
+add_one(a, b.copy(), c)
 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 `c` is changed as a result of the function call:
 ```
-a:10 b:[4, 3, 2, 1] c:[4, 3, 2]
+a:(4, 3, 2) b:[4, 3, 2] c:[4, 3, 2, 1]
 ```
 
+This is because `a` 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 `b`, its original value is not changed by the function. 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 is `c`, so only that values is changed as a result of the function call.
+
+
 ### 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 |
@@ -462,8 +465,8 @@ Different aspects of memory_graph can be configured. The default configuration i
 - ***memory_graph.config.max_string_length*** : int
   - The maximum length of strings shown in the graph. Longer strings will be truncated.
 
-- ***memory_graph.config.no_reference_types*** : dict
-  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node. It maps each type to a function that determines how it is visualized.
+- ***memory_graph.config.not_node_types*** : set
+  - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node.
 
 - ***memory_graph.config.no_child_references_types*** : set
   - The set of key_value types that don't draw references to their direct childeren but have their children shown as elements of their node.
@@ -550,5 +553,3 @@ See for example [jupyter_example.ipynb](https://raw.githubusercontent.com/bterwi
 
 - When graph edges overlap it can be hard to distinguish them. Using an interactive graphviz viewer, such as [xdot](https://github.com/jrfonseca/xdot.py), on a '*.gv' DOT output file will help.
 
-
-

{memory_graph-0.3.2 → memory_graph-0.3.4}/setup.py

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