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@44 | 28 | Other costly operations
|
paul@44 | 29 |
|
paul@44 | 30 | * Keyword parameter resolution
|
paul@44 | 31 | * Binary operators
|
paul@44 | 32 | * Comparisons
|
paul@44 | 33 |
|
paul@44 | 34 | Examples of rarely used/unnecessary flexibility
|
paul@44 | 35 |
|
paul@44 | 36 | * Can subclass dynamically:
|
paul@44 | 37 |
|
paul@44 | 38 | for cls in A, B:
|
paul@44 | 39 | class C(cls):
|
paul@44 | 40 | pass
|
paul@44 | 41 |
|
paul@44 | 42 | * Yet most people would relate to "class C"
|
paul@44 | 43 | * Not "the class currently known as C"
|
paul@44 | 44 |
|
paul@44 | 45 | Examples of occasionally used flexibility
|
paul@44 | 46 |
|
paul@44 | 47 | * Can evaluate classes and functions in dynamic contexts:
|
paul@44 | 48 |
|
paul@44 | 49 | if platform == 'posix':
|
paul@44 | 50 | class C:
|
paul@44 | 51 | ...
|
paul@44 | 52 | else:
|
paul@44 | 53 | class C:
|
paul@44 | 54 | ...
|
paul@44 | 55 |
|
paul@44 | 56 | * Seen quite often in the standard library with functions
|
paul@44 | 57 | * Dynamism used for configuration purposes
|
paul@44 | 58 |
|
paul@44 | 59 | Distinguish between "good" and "bad" dynamism
|
paul@44 | 60 |
|
paul@44 | 61 | * Dynamic class preparation
|
paul@44 | 62 | * Run-time choice of classes
|
paul@44 | 63 | * Assigning attributes to modules
|
paul@44 | 64 |
|
paul@44 | 65 | Run-time configuration
|
paul@44 | 66 |
|
paul@44 | 67 | * The source of a lot of "bad" dynamism
|
paul@44 | 68 | * Comparable to, but more robust than...
|
paul@44 | 69 | * Class loading tricks in Java
|
paul@44 | 70 | * Dynamic library loading magic in C/C++
|
paul@44 | 71 | * Has a place, but perhaps not in compiled, embedded programs
|
paul@49 | 72 |
|
paul@49 | 73 | Micropython modules
|
paul@49 | 74 |
|
paul@49 | 75 | * Modules contain attributes as with normal Python
|
paul@49 | 76 | * Inside the module:
|
paul@49 | 77 | * Attributes can be accessed and set as globals
|
paul@49 | 78 | * Classes and functions define module attributes
|
paul@49 | 79 | * Outside the module:
|
paul@49 | 80 | * Attributes can be accessed but not set
|
paul@49 | 81 | * Definition from within means more predictable content
|
paul@49 | 82 |
|
paul@49 | 83 | Micropython classes
|
paul@49 | 84 |
|
paul@49 | 85 | * Classes contain attributes and expose superclass attributes
|
paul@49 | 86 | * Inside the class:
|
paul@49 | 87 | * Attributes can be accessed and set in the class scope
|
paul@49 | 88 | * Functions define methods
|
paul@49 | 89 | * Outside the class:
|
paul@49 | 90 | * Attributes can be accessed but not set
|
paul@49 | 91 | * Definition from within means more predictable content
|
paul@49 | 92 |
|
paul@49 | 93 | Micropython instances
|
paul@49 | 94 |
|
paul@49 | 95 | * Instances contain attributes and expose class attributes
|
paul@49 | 96 | * Instance attributes must not shadow class attributes
|
paul@49 | 97 | * The set of attributes is detected by scanning the __init__ method
|
paul@49 | 98 |
|
paul@49 | 99 | Rationale for restrictions
|
paul@49 | 100 |
|
paul@49 | 101 | * Construct efficient run-time representations
|
paul@49 | 102 | * Predictable content means that access can be optimised
|
paul@49 | 103 | * No shadowing means that only a single lookup is necessary
|
paul@53 | 104 |
|
paul@53 | 105 | References, attributes and values
|
paul@53 | 106 |
|
paul@53 | 107 | * Almost everything can be considered as a kind of attribute:
|
paul@53 | 108 | * Module, class, instance
|
paul@53 | 109 | * Local variable is the exception
|
paul@53 | 110 | * Acquired attributes are "values":
|
paul@53 | 111 | * An object being manipulated
|
paul@53 | 112 | * Its context
|
paul@53 | 113 | * Most kinds of values have no real context:
|
paul@53 | 114 | * Module and class attributes, locals
|
paul@53 | 115 | * The exception:
|
paul@53 | 116 | * Instance attributes
|