1 Micropython: A minimal implementation of Python for constrained devices
2
3 * Python provides a rich programming environment
4 * CPython enforces the "official" language version
5 * CPython, Jython, etc. expose the full strength language
6
7 Motivations
8
9 * Run Python programs in "small" devices
10 * Small programs
11 * Few executed instructions
12
13 Python's flexibility comes at a cost
14
15 * Modules, classes, instances are all objects
16 * Freedom to modify most objects at any time
17 * Difficult to predict eventual behaviour before execution
18 * Difficult to generate optimisations when compiling
19
20 Attribute access
21
22 * Must do a full lookup every time:
23 * Check instance dictionary
24 * Check class, superclasses
25 * Potentially lots of code
26 * Lots of executed instructions
27
28 Improving attribute access performance
29
30 * Achieve faster access using a different representation
31 * Must define attributes of objects in advance
32 * Restriction: modules, classes, instances are "closed"
33 * Evaluate the limitations: are they too disruptive?
34
35 Consequences of revised attribute access
36
37 * Cannot extend the range of attributes on objects
38 * Further optimisations:
39 * Restriction: attempt to control modification of attributes
40 * Result: further optimisation of accesses
41
42 Invocations
43
44 * Target checking
45 * Number of arguments vs. number of parameters
46 * Keyword parameter resolution
47 * Defaults
48
49 Other costly operations
50
51 * Binary operators
52 * Comparisons
53
54 Examples of rarely used/unnecessary flexibility
55
56 * Can subclass dynamically:
57
58 for cls in A, B:
59 class C(cls):
60 pass
61
62 * Yet most people would relate to "class C"
63 * Not "the class currently known as C"
64
65 Examples of occasionally used flexibility
66
67 * Can evaluate classes and functions in dynamic contexts:
68
69 if platform == 'posix':
70 class C:
71 ...
72 else:
73 class C:
74 ...
75
76 * Seen quite often in the standard library with functions
77 * Dynamism used for configuration purposes
78
79 Distinguish between "good" and "bad" dynamism
80
81 * Dynamic class preparation
82 * Run-time choice of classes
83 * Assigning attributes to modules
84
85 Run-time configuration
86
87 * The source of a lot of "bad" dynamism
88 * Comparable to, but more robust than...
89 * Class loading tricks in Java
90 * Dynamic library loading magic in C/C++
91 * Has a place, but perhaps not in compiled, embedded programs
92
93 Micropython modules
94
95 * Modules contain attributes as with normal Python
96 * Inside the module:
97 * Attributes can be accessed and set as globals
98 * Classes and functions define module attributes
99 * Outside the module:
100 * Attributes can be accessed but not set
101 * Definition from within means more predictable content
102
103 Micropython classes
104
105 * Classes contain attributes and expose superclass attributes
106 * Inside the class:
107 * Attributes can be accessed and set in the class scope
108 * Functions define methods
109 * Outside the class:
110 * Attributes can be accessed but not set
111 * Definition from within means more predictable content
112
113 Micropython instances
114
115 * Instances contain attributes and expose class attributes
116 * Instance attributes must not shadow class attributes
117 * The set of attributes is detected by scanning the __init__ method
118
119 Rationale for restrictions
120
121 * Construct efficient run-time representations
122 * Predictable content means that access can be optimised
123 * No shadowing means that only a single lookup is necessary
124
125 References, attributes and values
126
127 * Almost everything can be considered as a kind of attribute:
128 * Module, class, instance
129 * Local variable is the exception
130 * Acquired attributes are "values":
131 * An object being manipulated
132 * Its context
133 * Most kinds of values have no real context:
134 * Module and class attributes, locals
135 * The exception:
136 * Instance attributes
