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