Skip to content

pyproject.toml: Make ruff aware of MicroPython builtins. - #1156

Open
agatti wants to merge 1 commit into
micropython:masterfrom
agatti:ruff-builtins
Open

pyproject.toml: Make ruff aware of MicroPython builtins.#1156
agatti wants to merge 1 commit into
micropython:masterfrom
agatti:ruff-builtins

Conversation

@agatti

@agatti agatti commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Note: This is the micropython-lib counterpart of micropython/micropython#19501. I forgot to submit this at the same time as the other PR, but GitHub doesn't make cross-repo PRs that easy to submit... :(

I've copied the PR's description here for completeness.

Summary

This PR updates the project-wide configuration for ruff, in order to not let it flag usages of MicroPython-specific types and keywords when performing code checks.

The tool currently has an exceptions list that covers almost all Python code that ships with MicroPython, however code placed in ports/<port>/modules (or elsewhere in the source tree where they're not covered by the exceptions list) by users for customisation purposes will end up raising errors for otherwise valid MicroPython-flavoured code.

Changes only let ruff assume that it knows about the existence of the micropython module (used without an initial import) for decorators (eg. native, viper, asm_..., etc.), Viper pointer types (ptr, ptr8, ptr16, ptr32), the unsigned integer return type (uint), the const constructor, and the execfile builtin.

For code that is placed elsewhere, these rules won't apply, so it might be an option to add further configuration instructions in the "getting started" documentation files.

Testing

Using this simple Python script:

@micropython.viper
def f(a: ptr8) -> uint:
    o = const(0)
    return a[o]

Without these changes, running ruff check <file> would yield this:

$ ruff check ptr.py
F821 Undefined name `micropython`
 --> ptr.py:1:2
  |
1 | @micropython.viper
  |  ^^^^^^^^^^^
2 | def f(a: ptr8) -> uint:
3 |     o = const(0)
  |

F821 Undefined name `ptr8`
 --> ptr.py:2:10
  |
1 | @micropython.viper
2 | def f(a: ptr8) -> uint:
  |          ^^^^
3 |     o = const(0)
4 |     return a[o]
  |

F821 Undefined name `uint`
 --> ptr.py:2:19
  |
1 | @micropython.viper
2 | def f(a: ptr8) -> uint:
  |                   ^^^^
3 |     o = const(0)
4 |     return a[o]
  |

F821 Undefined name `const`
 --> ptr.py:3:9
  |
1 | @micropython.viper
2 | def f(a: ptr8) -> uint:
3 |     o = const(0)
  |         ^^^^^
4 |     return a[o]
  |

Found 4 errors.

With these changes, instead:

$ ruff check ptr.py
All checks passed!

Trade-offs and Alternatives

This may potentially cause some false-negatives, like for example, allowing things like ptr types in non @micropyhon.viper-decorated functions.

ruff does not currently have any facility for plugins, otherwise it could be possible to traverse the AST being checked to easily see when MicroPython-specific constructs are safe to use.

Generative AI

I did not use generative AI tools when creating this PR.

This commit updates the project-wide configuration for `ruff`, in order
to not let it flag usages of MicroPython-specific types and keywords
when performing code checks.

The tool currently has an exceptions list that covers almost all Python
code that ships with MicroPython, however code placed in
`ports/<port>/modules` (or elsewhere) by users for customisation
purposes will end up raising errors for otherwise valid
MicroPython-flavoured code.

Changes only let `ruff` assume that it knows about the existence of the
`micropython` module (used without an initial import) for decorators
(eg. `native`, `viper`, `asm_...`, etc.), Viper pointer types (`ptr`,
`ptr8`, `ptr16`, `ptr32`), the unsigned integer return type (`uint`),
the `const` constructor, and the `execfile` builtin.

For code that is placed elsewhere, these rules won't apply, so it might
be an option to add further configuration instructions in the "getting
started" documentation files.

Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant