With the increasing number of MicroPython targets, writing portable code has become problematic. An example in https://github.com/micropython/micropython/pull/5553 is the issue with the machine.RTC class, where available methods vary between platforms. Another example was where code tested on a Pyboard 1.x, Pyboard D, ESP8266 and ESP32 failed on a Pyboard Lite: alone among these platforms it lacks uos.urandom(), a fact missing from the uos docs.

There are also core language features which can be enabled or disabled at compile time.

The general question is how can you establish the set of platforms compatible with a given script? Empirical testing has obvious drawbacks. The approach of trawling through the build system (bearing in mind that release builds may differ from daily builds) is difficult. As the number of ports increases it becomes increasingly laborious; further the build system may be a moving target.

These potential solutions come to mind, but maybe there is a better way.

1. Amend the docs for each new target. This seems hopelessly unwieldy, with each port generating a cascade of PR's and the docs becoming harder to read.
2. Have a database which could be queried by users. Ideally this would be automatically updated: is this feasible?
3. Define a reference build. This would include a defined set of features. In cases where the reference build does not support a feature, the official docs would state the fact - perhaps by a typographic convention. The build would be chosen to be fairly minimal with the hope that most ports would offer a superset. Each port would document its functionality with reference to that build. Program authors wanting portability would target that reference build, and could document their code accordingly.

The option of defining the reference build as an absolute minimum of functionality supported by all ports is too restrictive (e.g. no floating point).