memory-graph 0.3.23__tar.gz → 0.3.25__tar.gz

{memory_graph-0.3.23/memory_graph.egg-info → memory_graph-0.3.25}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: memory_graph
-Version: 0.3.23
+Version: 0.3.25
 Summary: Generate intuitive graphs of your Python data, great for debugging and understanding complex relationships.
 Home-page: https://github.com/bterwijn/memory_graph
 Author: Bas Terwijn
@@ -24,6 +24,11 @@ pip install --upgrade memory_graph
 ```
 Additionally [Graphviz](https://graphviz.org/download/) needs to be installed.
 
+# Videos #
+| [![Quick Intro](https://img.youtube.com/vi/8csmPga6Upw/0.jpg)](https://www.youtube.com/watch?v=8csmPga6Upw) | [![Mutability](https://img.youtube.com/vi/pvIJgHCaXhU/0.jpg)](https://www.youtube.com/watch?v=pvIJgHCaXhU) |
+|:--:|:--:|
+| [Quick Intro](https://www.youtube.com/watch?v=8csmPga6Upw) | [Mutability](https://www.youtube.com/watch?v=pvIJgHCaXhU) |
+
 # Memory Graph #
 For program understanding and debugging, the [memory_graph](https://pypi.org/project/memory-graph/) package can visualize your data, supporting many different data types, including but not limited to:
 
@@ -93,13 +98,6 @@ identical?: True
 ```
 A better way to understand what data is shared is to draw a graph of the data using the [memory_graph](https://pypi.org/project/memory-graph/) package.
 
-# Videos #
-
-| [![Mutability](https://img.youtube.com/vi/pvIJgHCaXhU/0.jpg)](https://www.youtube.com/watch?v=pvIJgHCaXhU) |
-|:--:|
-| [Mutability](https://www.youtube.com/watch?v=pvIJgHCaXhU) |
-
-
 # Chapters #
 
 [Python Data Model](#python-data-model)
@@ -108,7 +106,7 @@ A better way to understand what data is shared is to draw a graph of the data us
 
 [Debugging](#Debugging)
 
-[Datastructure Examples](#datastructure-examples)
+[Data Structure Examples](#data-structure-examples)
 
 [Configuration](#configuration)
 
@@ -116,6 +114,8 @@ A better way to understand what data is shared is to draw a graph of the data us
 
 [Introspection](#introspection)
 
+[Introspection Depth](#introspection-depth)
+
 [Jupyter Notebook](#jupyter-notebook)
 
 [ipython](#ipython)
@@ -137,14 +137,14 @@ Inspired by [Python Tutor](https://pythontutor.com/).
 ___
 ___
 
-## Python Data Model ##
+# Python Data Model #
 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, set, dict, classes, ... (most other types)
 
 
-### Immutable Type ###
+## Immutable Type ##
 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 `b` its value **cannot** be mutated in place, and thus an automatic copy is made and `a` and `b` reference a different value afterwards.
 
 ```python
@@ -162,7 +162,7 @@ mg.render(locals(), 'immutable2.png')
 | immutable1.png | immutable2.png |
 
 
-### Mutable Type ###
+## Mutable Type ##
 With mutable types the result is different. In the code below variable `a` and `b` both reference the same `list` value [4, 3, 2]. A `list` is a mutable type and therefore when we change variable `b` its value **can** be mutated in place and thus `a` and `b` both reference the same new value afterwards. Thus changing `b` also changes `a` and vice versa. Sometimes we want this but other times we don't and then we will have to make a copy ourselfs so that `a` and `b` are independent.
 
 ```python
@@ -181,7 +181,7 @@ mg.render(locals(), 'mutable2.png')
 
 One practical reason why Python makes the distinction between mutable and immutable types is that a value of a mutable type can be large, making it inefficient to copy each time we change it. Immutable values generally don't need to change as much, or are small making copying less of a concern.
 
-### Copying ###
+## Copying ##
 Python offers three different "copy" options that we will demonstrate using a nested list:
 
 ```python
@@ -205,7 +205,7 @@ mg.show(locals())
 ![copies.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/copies.png)
 
 
-### Custom Copy ###
+## Custom Copy ##
 We can write our own custom copy function or method in case the three standard "copy" options don't do what we want. For example, in the code below the copy() method of My_Class copies the `digits` but shares the `letters` between two objects.
 
 ```python
@@ -231,7 +231,7 @@ mg.show(locals())
 ```
 ![copy_method.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/copy_method.png)
 
-### Name Rebinding ###
+## Name Rebinding ##
 When `a` and `b` share a mutable value, then changing the value of `b` changes the value of `a` and vice versa. However, reassigning `b` does not change `a`. When you reassign `b`, you only rebind the name `b` to a new value without effecting any other variables.
 
 ```python
@@ -249,7 +249,7 @@ mg.render(locals(), 'rebinding2.png')
 |:-----------------------------------------------------------:|:-------------------------------------------------------------:|
 | rebinding1.png | rebinding2.png |
 
-## Call Stack ##
+# Call Stack #
 The `mg.stack()` function retrieves the entire call stack, including the local variables for each function on the stack. This enables us to visualize the local variables across all active functions simultaneously. By examining the graph, we can determine whether any local variables from different functions share data. For instance, consider the function `add_one()` which adds the value `1` to each of its parameters `a`, `b`, and `c`.
 
 ```python
@@ -277,7 +277,7 @@ 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.
 
-### Block ###
+## Block ##
 It is often helpful to temporarily block program execution to inspect the graph. For this we can use the `mg.block()` function:
 
 ```python
@@ -294,7 +294,7 @@ To change its behavior:
 * Set `mg.block_prints_location = False` to skip printing the source location.
 * Set `mg.press_enter_message = None` to skip printing "Press &lt;Enter&gt; to continue...".
 
-### Recursion ###
+## Recursion ##
 The call stack is also helpful to visualize how recursion works. Here we use `mg.block()` to show each step of how recursively ```factorial(3)``` is computed:
 
 ```python
@@ -315,7 +315,7 @@ print(factorial(3))
 
 and the result is: 1 x 2 x 3 = 6
 
-### Power Set ###
+## Power Set ##
 A more interesting recursive example that shows sharing of data is power_set(). A power set is the set of all subsets of a collection of values.
 
 ```python
@@ -345,7 +345,7 @@ print( power_set(['a', 'b', 'c']) )
 [['a', 'b', 'c'], ['a', 'b'], ['a', 'c'], ['a'], ['b', 'c'], ['b'], ['c'], []]
 ```
 
-## Debugging ##
+# Debugging #
 
 For the best debugging experience with memory_graph set for example expression:
 ```
@@ -353,7 +353,7 @@ mg.render(locals(), "my_graph.pdf")
 ```
 as a *watch* in a debugger tool such as the integrated debugger in Visual Studio Code. Then open the "my_graph.pdf" output file to continuously see all the local variables while debugging. This avoids having to add any memory_graph `show()` or `render()` calls to your code.
 
-### Call Stack in Watch Context ###
+## Call Stack in Watch Context ##
 The ```mg.stack()``` doesn't work well in *watch* 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 |
@@ -364,7 +364,7 @@ The ```mg.stack()``` doesn't work well in *watch* context in most debuggers beca
 
 ![debug_vscode.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/debug_vscode.png)
 
-#### Other Debuggers ####
+## Other Debuggers ##
 For other debuggers, invoke this function within the *watch* context. Then, in the "call_stack.txt" file, identify the slice of functions you wish to include in the call stack.
 ```
 mg.save_call_stack("call_stack.txt")
@@ -374,7 +374,7 @@ Choose 'after' and 'up_to' what function you want to slice and then call this fu
 mg.stack_after_up_to(after_function, up_to_function="<module>")
 ```
 
-### Debugging without Debugger Tool ###
+## Debugging without Debugger Tool ##
 
 To simplify debugging without a debugger tool, we offer these alias functions that you can insert into your code at the point where you want to visualize a graph:
 
@@ -407,48 +407,44 @@ and pressing &lt;Enter&gt; a number of times, results in:
 
 ![debugging.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/debugging.gif)
 
-## Datastructure Examples ##
-Module memory_graph can be very useful in a course about datastructures, some examples:
+# Data Structure Examples #
+Module memory_graph can be very useful in a course about data structures, some examples:
 
-### Doubly Linked List ###
+## Doubly Linked List ##
 ```python
 import memory_graph as mg
 import random
 random.seed(0) # use same random numbers each run
 
-class Node:
+class Linked_List:
 
-    def __init__(self, value):
-        self.prev = None
+    def __init__(self, value=None, prev=None, next=None):
+        self.prev = prev
         self.value = value
-        self.next = None
-
-class LinkedList:
-
-    def __init__(self):
-        self.head = None
-        self.tail = None
+        self.next = next
 
     def add_front(self, value):
-        new_node = Node(value)
-        if self.head is None:
-            self.head = new_node
-            self.tail = new_node
+        if self.value == None:
+            self.value = value 
+        elif self.next is None:
+            new_node = Linked_List(value)
+            self.prev = new_node
+            self.next = new_node
         else:
-            new_node.next = self.head
-            self.head.prev = new_node
-            self.head = new_node
-        mg.block(mg.show, locals()) # <--- draw locals
+            new_node = Linked_List(value, self.next)
+            self.next.next = new_node
+            self.next = new_node
 
-linked_list = LinkedList()
+linked_list = Linked_List()
 n = 100
 for i in range(n):
-    new_value = random.randrange(n)
-    linked_list.add_front(new_value)
+    value = random.randrange(n)
+    linked_list.add_front(value)
+	mg.show(locals())
 ```
 ![linked_list.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/linked_list.png)
 
-### Binary Tree ###
+## Binary Tree ##
 ```python
 import memory_graph as mg
 import random
@@ -484,7 +480,7 @@ for i in range(n):
 ```
 ![bin_tree.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/bin_tree.png)
 
-### Hash Set ###
+## Hash Set ##
 ```python
 import memory_graph as mg
 import random
@@ -523,34 +519,44 @@ for i in range(n):
 ![hash_set.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/hash_set.png)
 
 
-## Configuration ##
+# Configuration #
 Different aspects of memory_graph can be configured. The default configuration is reset by importing 'memory_graph.config_default'.
 
-- ***mg.config.max_graph_depth*** : int
-  - The maxium depth of the graph with default value 12. A `✂` (scissor) symbol indicates where the graph is cut short. Dashed references indicate that there are more references to a node than are shown.
-
 - ***mg.config.max_string_length*** : int
   - The maximum length of strings shown in the graph. Longer strings will be truncated.
 
-- ***mg.config.not_node_types*** : set
+- ***mg.config.not_node_types*** : set[type]
   - Holds all types for which no seperate node is drawn but that instead are shown as elements in their parent Node.
 
-- ***mg.config.no_child_references_types*** : set
+- ***mg.config.no_child_references_types*** : set[type]
   - 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.
 
-- ***mg.config.type_to_node*** : dict
+- ***mg.config.type_to_node*** : dict[type, fun(data) -> Node]
   - Determines how a data types is converted to a Node (sub)class for visualization in the graph.
 
-- ***mg.config.type_to_color*** : dict
-  - Maps each type to the [graphviz color](https://graphviz.org/doc/info/colors.html) it gets in the graph. 
+- ***mg.config.type_to_color*** : dict[type, color]
+  - Maps a type to the [graphviz color](https://graphviz.org/doc/info/colors.html) it gets in the graph. 
+
+- ***mg.config.type_to_vertical_orientation*** : dict[type, bool]
+  - Maps a type to its orientation. Use 'True' for vertical and 'False' for horizontal. If not specified Node_Linear and Node_Key_Value are vertical unless they have references to children.
+
+- ***mg.config.type_to_slicer*** : dict[type, int]
+  - Maps a type to a Slicer. A slicer determines how many elements of a data type are shown in the graph to prevent the graph from getting too big. 'Slicer()' does no slicing, 'Slicer(1,2,3)' shows just 1 element at the beginning, 2 in the middle, and 3 at the end.
+
+- ***mg.config.max_graph_depth*** : int
+  - The maxium depth of the graph with default value 12.
+
+- ***config.graph_cut_symbol*** : str
+  - The symbol indicating where the graph is cut short with default `✂`.
+  
+- ***mg.config.type_to_depth*** : dict[type, int]
+  - Maps a type to graph depth to limit the graph size.
 
-- ***mg.config.type_to_vertical_orientation*** : dict
-  - Maps each type to its orientation. Use 'True' for vertical and 'False' for horizontal. If not specified Node_Linear and Node_Key_Value are vertical unless they have references to children.
+- ***max_missing_edges*** : int
+  - Maximum number of missing edges that are shown with default value 2. Dashed references are used to indicate that there are more references to a node than are shown.
 
-- ***mg.config.type_to_slicer*** : dict
-  - Maps each type to a Slicer. A slicer determines how many elements of a data type are shown in the graph to prevent the graph from getting too big. 'Slicer()' does no slicing, 'Slicer(1,2,3)' shows just 1 element at the beginning, 2 in the middle, and 3 at the end.
 
-### Simplified Graph ###
+## Simplified Graph ##
 Memory_graph simplifies the visualization (and the viewer's mental model) by **not** showing separate nodes for immutable types like `bool`, `int`, `float`, `complex`, and `str` by default. This simplification can sometimes be slightly misleading. As in the example below, after a shallow copy, lists `a` and `b` technically share their `int` values, but the graph makes it appear as though `a` and `b` each have their own copies. However, since `int` is immutable, this simplification will never lead to unexpected changes (changing `a` won’t affect `b`) so will never result in bugs.
 
 The simplification strikes a balance: it is slightly misleading but keeps the graph clean and easy to understand and focuses on the mutable types where unexpected changes can occur. This is why it is the default behavior. If you do want to show separate nodes for `int` values, such as for educational purposes, you can simply remove `int` from the `mg.config.not_node_types` set:
@@ -571,7 +577,7 @@ mg.render(locals(), 'not_node_types2.png')
 
 Additionally, the simplification hides away the [reuse of small int values](https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong) in the current CPython implementation, an optimization that might otherwise confuse beginner Python programmers. For instance, after executing `a[1]+=1; b[1]+=1` the `201` value is, maybe surprisingly, still shared between `a` and `b`, whereas executing `a[2]+=1; b[2]+=1` does not result in sharing the `301` value.
 
-### Temporary Configuration ###
+## Temporary Configuration ##
 In addition to the global configuration, a temporary configuration can be set for a single `show()` or `render()` call to change the colors, orientation, and slicer. This example highlights a particular list element in red, gives it a horizontal orientation, and overwrites the default slicer for lists:
 
 ```python
@@ -589,10 +595,10 @@ mg.show( locals(),
 ```
 ![highlight.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/highlight.png)
 
-## Extensions ##
+# Extensions #
 Different extensions are available for types from other Python packages. 
 
-### Numpy ###
+## Numpy ##
 Numpy types `array` and `matrix` and `ndarray` can be graphed with "memory_graph.extension_numpy":
 
 ```python
@@ -608,7 +614,7 @@ mg.show(locals())
 ```
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/extension_numpy.png)
 
-### Pandas ###
+## Pandas ##
 Pandas types `Series` and `DataFrame` can be graphed with "memory_graph.extension_pandas":
 
 ```python
@@ -627,7 +633,7 @@ mg.show(locals())
 ```
 ![extension_pandas.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/extension_pandas.png)
 
-## Introspection ##
+# Introspection #
 This section is likely to change. Sometimes the introspection fails or is not as desired. For example the `bintrees.avltree.Node` object doesn't show any attributes in the graph below.
 
 ```python
@@ -646,7 +652,7 @@ mg.show(locals())
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/avltree_fail.png)
 
 
-### dir() ###
+## All attributes using dir() ##
 A useful start is to give it some color, show the list of all its attributes using `dir()`, and setting an empty Slicer to see the attribute list in full.
 
 ```python
@@ -671,7 +677,7 @@ mg.show(locals())
 
 Next figure out what are the attributes you want to graph and choose a Node type, there are four options:
 
-### 1) Node_Leaf ###
+## 1) Node_Leaf ##
 Node_Leaf is a node with no children and shows just a single value.
 ```python
 import memory_graph as mg
@@ -692,7 +698,7 @@ mg.show(locals())
 ```
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/avltree_leaf.png)
 
-### 2) Node_Linear ###
+## 2) Node_Linear ##
 Node_Linear shows multiple values in a line like a list.
 ```python
 import memory_graph as mg
@@ -716,7 +722,7 @@ mg.show(locals())
 ```
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/avltree_linear.png)
 
-### 3) Node_Key_Value ###
+## 3) Node_Key_Value ##
 Node_Key_Value shows key-value pairs like a dictionary. Note the required `items()` call at the end.
 ```python
 import memory_graph as mg
@@ -740,7 +746,7 @@ mg.show(locals())
 ```
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/avltree_key_value.png)
 
-### 4) Node_Table ###
+## 4) Node_Table ##
 Node_Table shows all the values as a table.
 ```python
 import memory_graph as mg
@@ -764,7 +770,75 @@ mg.show(locals())
 ![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/avltree_table.png)
 
 
-## Jupyter Notebook ##
+# Introspection Depth #
+To limit the size of the graph the maximum depth of the graph is set by `mg.config.max_graph_depth`. Additionally for each type a depth can be set to further limit the graph, as is done for type `B` in the example below. Scissors indicate where the graph is cut short. Alternatively the `id()` of a data elements can be used to limit the graph for that specific element, as is done for the value referenced by variable `c`.
+
+The value of variable `x` is shown as it is at depth 1 from the root of the graph, but as it can also be reached via `b2`, that path need to be shown as well to avoid confusion, so this overwrites the depth limit set for type `B`.
+
+```python
+import memory_graph as mg
+
+class Base:
+
+    def __init__(self, n):
+        self.elements = [1]
+        iter = self.elements
+        for i in range(2,n):
+            iter.append([i])
+            iter = iter[-1]
+
+    def get_last(self):
+        iter = self.elements
+        while len(iter)>1:
+            iter = iter[-1]
+        return iter
+            
+class A(Base):
+
+    def __init__(self, n):
+        super().__init__(n)
+
+class B(Base):
+
+    def __init__(self, n):
+        super().__init__(n)
+
+class C(Base):
+
+    def __init__(self, n):
+        super().__init__(n)
+
+a = A(6)
+b1 = B(6)
+b2 = B(6)
+c = C(6)
+
+x = ['x']
+b2.get_last().append(x)
+
+mg.config.type_to_depth[B] = 3
+mg.config.type_to_depth[id(c)] = 2
+mg.show(locals())
+```
+![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/introspect_depth.png)
+
+## Hidden Edges ##
+
+As the value of `x` is shown in the graph, we would want to show all the references to it, but the default list Slicer hides references by slicing the list to keep the graph small. The `max_missing_edges` variable then determines how many additional hidden references to `x` we show. If there are more references then we show, then theses hidden references are shown with dashed lines to indicate some references are left out.
+
+```python
+import memory_graph as mg
+
+data = []
+x = ['x']
+for i in range(20):
+    data.append(x)
+
+mg.show(locals())
+```
+![extension_numpy.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/hidden_edges.png)
+
+# Jupyter Notebook #
 In Jupyter Notebook `locals()` has additional variables that cause problems in the graph, use `mg.locals_jupyter()` to get the local variables with these problematic variables filtered out. Use `mg.stack_jupyter()` to get the whole call stack with these variables filtered out.
 
 We can use `mg.show()` and `mg.render()` in a Jupyter Notebook, but alternatively we can also use `mg.create_graph()` to create a graph and the `display()` function to render it inline with for example:
@@ -777,7 +851,7 @@ mg.block(display, mg.create_graph(mg.locals_jupyter()) ) # the same but blocked
 See for example [jupyter_example.ipynb](https://raw.githubusercontent.com/bterwijn/memory_graph/main/src/jupyter_example.ipynb).
 ![jupyter_example.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/jupyter_example.png)
 
-## ipython ##
+# ipython #
 In ipython `locals()` has additional variables that cause problems in the graph, use `mg.locals_ipython()` to get the local variables with these problematic variables filtered out. Use `mg.stack_ipython()` to get the whole call stack with these variables filtered out.
 
 Additionally install file [auto_memory_graph.py](https://raw.githubusercontent.com/bterwijn/memory_graph/main/src/auto_memory_graph.py) in the ipython startup directory:
@@ -787,15 +861,15 @@ Additionally install file [auto_memory_graph.py](https://raw.githubusercontent.c
 Then after starting 'ipython' call function `mg_switch()` to turn on/off the automatic visualization of local variables after each command.
 ![ipyton.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/ipython.png)
 
-## In the Browser ##
+# In the Browser #
 We can also run memory_graph in the browser: <a href="https://bterwijn.github.io/memory_graph/src/pyodide.html" target="_blank">Pyodide Example</a>
 ![pyodide.png](https://raw.githubusercontent.com/bterwijn/memory_graph/main/images/pyodide.png)
 
-## Troubleshooting ##
+# Troubleshooting #
 
 - Adobe Acrobat Reader [doesn't refresh a PDF file](https://community.adobe.com/t5/acrobat-reader-discussions/reload-refresh-pdfs/td-p/9632292) when it changes on disk and blocks updates which results in an `Could not open 'somefile.pdf' for writing : Permission denied` error. One solution is to install a PDF reader that does refresh ([SumatraPDF](https://www.sumatrapdfreader.org/), [Okular](https://okular.kde.org/),  ...) and set it as the default PDF reader. Another solution is to `render()` the graph to a different output format and to open it manually.
 
 - 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.
 
-### Invocation_Tree Package ###
+## Invocation_Tree Package ##
 The [memory_graph](https://pypi.org/project/memory-graph/) package visualizes your data. If instead you want to visualize function calls, check out the [invocation_tree](https://pypi.org/project/invocation-tree/) package.