python-stdlib/unittest/unittest: Remove f-strings.

[agatti]

Summary

This PR removes usage of f-strings from the unittest module, in favour to the old printf-style raw string formatting operations.

The module is a bit special since it is meant to be also validate the behaviour of MicroPython interpreters, and those may come with any combination of configuration options. For example, f-strings are not available by default on some feature levels, and thus the test suite won't run cleanly on certain targets unless the support for that feature is explicitly enabled.

See the discussion at micropython/micropython#19111 for more information.

I've had a quick look at ruff's available rules and I didn't find a ruff rule that would prevent f-strings to reappear in the future, otherwise I'd have put the restriction in place for this file.

As a bonus, now the module is 31 bytes shorter :)

Testing

Overwriting the __init__.py file on a board compiled with MICROPY_CONFIG_ROM_LEVEL_CORE_FEATURES doesn't trigger a SyntaxError exception anymore. Tests in MicroPython's test suite that depend on unittest to be available on device now execute.

Generative AI

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

[dpgeorge]

Thanks for doing this.

While your at it, you could also remove the import os at the top, it's not needed, and eliminates a dependency.

(When I looked at this I wanted to convert all string formatting to "".format(...), because that's guaranteed to always be available, while % formatting is not due to MICROPY_PY_BUILTINS_STR_OP_MODULO. But that's a much bigger change, and anyway unittest won't work with less than MICROPY_CONFIG_ROM_LEVEL_CORE_FEATURES due to other things like io module.)

[agatti]

When I looked at this I wanted to convert all string formatting to "".format(...), because that's guaranteed to always be available

I admit I thought modulo was one of the features available on all profiles. I've simply followed the style of the rest of the code and made sure it worked on device. Still, if the minimum ROM level for this could be lowered even further that'd be nice somehow.

Once I'm done with the CH32V 64KiB and 128KiB MCUs I guess I can have a go at the lower-specced ones and see if this can be adapted to work on that too.