diff options
| author | Thea Flowers <me@thea.codes> | 2019-11-12 12:33:52 -0800 |
|---|---|---|
| committer | Thea Flowers <me@thea.codes> | 2019-11-26 13:09:30 -0800 |
| commit | 84e1d7f304fc92f69eb1120682fe91dff7188ddc (patch) | |
| tree | dd66f0fb4120d31835b4d6d1ca4cbe37d61ce23e /shared-module | |
| parent | e560b419f82dd650df039ba638969051bff10e28 (diff) | |
Make the @micropython.native decorator no-op if support isn't enabled
When adding the ability for boards to turn on the `@micropython.native`, `viper`, and `asm_thumb` decorators it was pointed out that it's somewhat awkward to write libraries and drivers that can take advantage of this since the decorators raise `SyntaxErrors` if they aren't enabled. In the case of `viper` and `asm_thumb` this behavior makes sense as they require writing non-normative code. Drivers could have a normal and viper/thumb implementation and implement them as such:
```python
try:
import _viper_impl as _impl
except SyntaxError:
import _python_impl as _impl
def do_thing():
return _impl.do_thing()
```
For `native`, however, this behavior and the pattern to work around it is less than ideal. Since `native` code should also be valid Python code (although not necessarily the other way around) using the pattern above means *duplicating* the Python implementation and adding `@micropython.native` in the code. This is an unnecessary maintenance burden.
This commit *modifies* the behavior of the `@micropython.native` decorator. On boards with `CIRCUITPY_ENABLE_MPY_NATIVE` turned on it operates as usual. On boards with it turned off it does *nothing*- it doesn't raise a `SyntaxError` and doesn't apply optimizations. This means we can write our drivers/libraries once and take advantage of speedups on boards where they are enabled.
Diffstat (limited to 'shared-module')
0 files changed, 0 insertions, 0 deletions
