Interesting discussion, I have a slightly different vantage point, that has not been mentioned before.
I use microcontrollers for private and professional purposes, and so far have been programming them in C or C++ (or assembler *duck*).
A year ago colleagues and friends started to tell me more and more about Python, and I started to look around for a system, that is powerful enough for every day use, yet comfortable to use, light weight and flexible to change, and (very important), a community with some support (I don't expect miracles though).
I am not yet interested in using Python on the PC, I am interested in a µC-system, that I can use to develop a solution (combination of hardware and software) fast and comfortable, and i want to use this for hobby and professional purposes as well.
In any case, being in my 50ies now, I realize how precious time is, and I don't know how many more languages and systems I will want to learn in my life.
I do not fit in any of Picasso's original categories, for me the important points are:
- A comfortable language, that enables me to develop fast solutions. Python is not perfect, but very good for that.
- Powerful: I don't want to use a multitude of different systems. I want one or two different controllers, that I know how to work with. And I am happy to pay a bit more, when they have the grunt to do what I want. I understand, that some people use cheapest hardware, if possible - I have made the experience, that this is a waste of my time and consequently of my money. I always reach the limits of these cheap systems too fast.
This becomes especially important when i am using microcontroller for professional purposes: One (!) engineering hour is more expensive than a PyBoardD. Depending on the scale of the endeavor, it is an easy calculation to do: how many engineering hours do I have to invest in a product until it is fit for purpose? How many units do I want to build? That determines my hardware cost. And when I am building small numbers of devices (let's say up to 10), my time is simply to precious to waste it by trying to jumping through hoops.
- Light weight. That is a very important point, because the programming and maintenance effort to develop a solution and keep source code up-to-date is growing exponentially with the size.
If the code is open-source, there is no obligation for anyone to service their code, in other words, I have to scrutinize every piece of code included into my own projects. Fair enough, it was free in first instance. But that takes time. And diligence. And it is much easier with a small system!
- Support. Well, when I use a system that someone sells for money, I may have access to support - but i am also more or less depending on that company having an interest in helping me, and especially as a private customer that can be challenging.
With open-source the community base must simply be large enough to support that system, and the drivers behind the development, aka the inventors, original developers and main contributors should be well involved.
- A more or less comfortable tool-chain - a no-brainer, I don't want to wrestle with the toolchain, the project itself is challenging enough.
MicroPython and the pyboards tick all these boxes. Especially the lightweight character of MicroPython and the direct access to the underlying hardware is a great plus. I can access everything I need, the processors are powerful enough, I can use C++, if i have to, and the contributors are doing a great job.
And finally, Python and MicroPython will always (!) be different to a degree, simply
because you are running an interpreted language without an operating system.
When you use a computer with an OS, the OS provides a Hardware Abstraction Layer, which must be reasonable complex. Running MicroPython leaves you without this HAL (and I appreciate this, I can write my own). Portability of the code and the commands of the particular implementation of MicroPython may differ slightly. You will always have to address these differences, and that means, to recognize the hardware capabilities.