RFC Writing portable code #5564
Comments
|
Peter, thanks for starting this! I'm divided in that right now all I care about is ESP32, so I really don't give a hoot about compatibility, I just want to know what works there and what doesn't. And I'm OK adding what doesn't and I'm really happy I can do that without having to buy a board of every other platform so I can implement it there too in order to get a PR merged. At the same time I'm not a maverick and agree that having more complete docs that break out what is supported where would help a lot. For one, it would actually make the differences visible. I'd read the docs and see that something isn't supported on the ESP32 and might spend the time to add it. The RTC situation, well, that's just appalling. But if the first implementation had been documented and there had been a hard rule that new additions (e.g. new ports) must update the docs I bet the problem would never have happened in the first place. (I strongly believe that making a hard rule thet any PR that wants to be merged must update docs is important: no doc update = no merge.) In terms of technical solution, could the If there's a number of people willing to commit a bit of time to improve the docs as a group effort I'm in. |
|
Thorsten, thanks for your comments.
Agreed. I'm happy to contribute to docs but I think option 1 is unmanageable. I'd like to see a technical solution which will solve the problem for current and future ports. The MicroPython project is enhanced by the availability of user-contributed code such as device drivers - it would be great if authors could state with confidence which platforms are supported.
I'm certainly not advocating that! There is a need to support port-specific methods, notably for hardware devices like the RTC. Using that example, basic methods such as (perhaps) |
|
In my opinion the problem can be split into two independent parts: core features configured by Furthermore, the solution to the problem can be in the docs and/or implementation. For features from We could provide unix builds at each level (eg Then a given port's Docs would list what is and is not available at each level, and a port's docs would say which level it supports. For things like the |
|
This sounds like a good solution. |
|
Maybe the use of something similar as used in linux and zephyr being the menuconfig utility. It gives a list of all options (may be varied depending on the port, could use default settings and options can be explained with additional help. It can generate the necessary work to do to recompile mpy-cross, select the right options, generate make/make build instructions etc. my2bits |
|
Most of my libraries aim to be used on any platform running a release binary. An aid to managing build options would be very useful, but it wouldn't actually address this problem. |
|
I've fallen foul of this yet again. I published code which uses f-strings, with docs mandating firmware >= 1.17. Today I discovered that the code fails on an ESP8266. As far as I can see, nowhere is it documented that some platforms don't support f-strings. Writing portable code is needlessly difficult - and you're left wondering what other features will barf on some platform or other. |
|
Many useful things said here. But what stabds out to me ate the following issues:
Documentation is often the last resort to technical limitations. In short, in this instance: If you are inconsistent, DOCUMENT IT! This is often a matter of ownership and responsibility (for a piece of code).
I like the approach of coverage levels mentioned in an earlier post. I have no clue about the extent of language features in Python. But I think a coverage strategy along the lines of "what is core, what are modules, what is SoC specific, and what is platform specific?" might help here. TL;DR To be helpful I'd like to make a number of suggestions:
Happy to help and discuss to find a good balance.
Seek to develop test coverage that is easy to run on platforms, gathering as much feedback on coverage and results as possible, as automated as possible. Then fan this out to your "army of platforms". I am sure many would consider joining if testing is easy and even perhaps relatively automated. I'd be available to test on Expressif ESP8266 and ESP32 dev kits.
Maybe try and find a XP style of buddying up with some of the testers?
I know I can fort the Github repo and start tinkering around to customise to what I want. But that is I think the right approach for those interested in developing mpy for a platform - but not for those who want to use it and develop ON TOP of of (like me). A horribly long post, but I hooe it is useful in some ways. |
|
P.S., the above was written on my mobile with "sausage fingers" akin to wearing mittens. So please excuse typos and other hiccups :-) |
See #7956. IMO f-strings are really useful and we should support them on the main ports, because otherwise, as you say, it's impossible to write portable code that uses f-strings. |
That is pretty much what was started in 01374d9, which still needs further work. |
|
Just to add a couple of cents worth, yes, documentation is very important and developers either hate doing it or leave it too late. But to add to the problem a great many developers hate _(re-)_reading documentation and only RTFM when things go wrong also too late. The generation of the lookup tables, (and the updating of the documents), could be vastly aided by having a required set of features for all platforms that either must be implemented or marked with a NOT_IMPLEMENTED macro and possibly a platform developer mode for linting with errors for missing features would be nice but probably it would be easier to address this by the make process issuing warnings. (errors in release mode), for each feature that is not either implemented or marked as specifically NOT_IMPLEMENTED. One thought might be to have more than none such flag, e.g. NOT_YET_IMPLEMENTED the developer plans to but hasn't yet, BETA_FEATURE not 100% tested use with caution, NO_HARDWARE_SUPPORT this platform lacks the supporting hardware to implement this. |
enable running asyncio
With the increasing number of MicroPython targets, writing portable code has become problematic. An example in #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.
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).
The text was updated successfully, but these errors were encountered: