Picasso wrote: ↑Sun Mar 24, 2019 8:14 pm
This response takes me a bit by surprise. I'm sure there is more to it than this.
I was under the impression that the name 'Micro' actually pointed to micro controllers,
No, who would want to waste their life on just microcontrollers? Besides, such projects already exist, e.g. PyMite, OwlPython, etc. All perfectly dead. Again, why waste life repeating their mistakes, instead of learning from them?
and not for example MicroHalonColliders.
MicroPython is not MicroHalonColliders, MicroPython is MicroAnything.
For many of the platforms (or field of applications) you are referring to, other Python platform already exist.
Great, the more reasons to not turn MicroPython into anything like them.
It seems to me, that it is difficult to do well if the focus is not clear.
The focus is absolutely and very clear - to be the minimal Python implementation.
Minimalism is not bad, but it seems that the new PYBD boards are capable of handling much more than just the absolut minimum.
You're apparently mix up MicroPython and specific products based on it. Rest assured that any vendor of a MicroPython product would add to it proprietary features in order to compete. That has little to do with MicroPython as a project which scales to millions of different boards.
Some smaller boards benefit from minimum. But more powerfull boards would benefit from more flexibility perhaps.
The purpose of MicroPython is the same as (big) Python - provide consistent programming environment regardless of hardware. Obviously, depending on the hardware, *user* applications will be different. The language and its API should be the same though, and in the case of MicroPython, minimal.
Is the architecture not in place to be flexible in these terms too? The core is minimum, the ports are per requirement of the boards, and additional drivers can be done in C but also in python.
MicroPython is way too flexible, most people don't even know its flexibility, far less using it. Regarding handling boards - that's of course how it is. Regarding "additional drivers": that has little to do with MicroPython. Additional drivers, modules, applications users develop and maintain on their own.
In that way, it would be possible to satisfy the 'non-firmware builders', and by doing so the community would prevent pushing a huge potential of micropython fanbase towards the commercial adafruit.
I'm not sure if it occurred to you, but any specific MicroPython product is a commercial endeavor, be it by George Robotics, PyCom, Adafruit, Sipeed, ST, NXP, etc. And each vendor will add glorious proprietary features to it to make their product "stand out". From the point of view of self-conscious MicroPython community, any board-specific features are bad - they fragment community and make writing portable software hard.