MicroPython 1.4.5(mail.python.org)
mail.python.org
MicroPython 1.4.5
https://mail.python.org/pipermail/python-announce-list/2015-August/010865.html
16 comments
Very interesting link, thanks! Shows very well viability and benefits of using Python on constrained systems.
Using message passing for concurrent programming is a well-known technique, it's nice that they tested it in embedded Python context. However, regarding syntax extensions - I wished they run them thru python-ideas list. Because otherwise all the pattern matching can be done in Python already, perhaps with a little more syntax - well, the paper links to http://candygram.sourceforge.net/ which implemented it 10+ years ago.
Using message passing for concurrent programming is a well-known technique, it's nice that they tested it in embedded Python context. However, regarding syntax extensions - I wished they run them thru python-ideas list. Because otherwise all the pattern matching can be done in Python already, perhaps with a little more syntax - well, the paper links to http://candygram.sourceforge.net/ which implemented it 10+ years ago.
Maybe there's a reason they implemented actors using extension ? performance/latency ?
Maybe you guys should collaborate with the guys behind the paper ? they can offer their expertise - and if they built it inside micropython, that means many more people will use the technology - and they will get much more academic citations.
Maybe you guys should collaborate with the guys behind the paper ? they can offer their expertise - and if they built it inside micropython, that means many more people will use the technology - and they will get much more academic citations.
I mostly refer to adding new syntax to the language (recv, pattern matching as described in that report). It's obvious why it was done - it's syntactic sugar which make programming easier. But it's no longer Python, a language many people know or run apps in. So I'd really like if embedded Python folks tried to run their ideas thru python-ideas list to get wider Python community feedback (and yep, we're trying to do our homework in that direction, and would hope to meet other embedded Python folks there).
> Maybe you guys should collaborate with the guys behind the paper ?
Definitely, I'm drafting a "Hello" email. And I think there's really opportunity for collaboration - they based Owl on PyMite, so I figure they don't fancy developing own VM from scratch, so if they'd be interested in Python3, here's MicroPython. And we could use feedback and wider discussion on topics of hardware access APIs. And prototyping various concurrency models for uPy would be just fantastic.
> Maybe you guys should collaborate with the guys behind the paper ?
Definitely, I'm drafting a "Hello" email. And I think there's really opportunity for collaboration - they based Owl on PyMite, so I figure they don't fancy developing own VM from scratch, so if they'd be interested in Python3, here's MicroPython. And we could use feedback and wider discussion on topics of hardware access APIs. And prototyping various concurrency models for uPy would be just fantastic.
What's wrong with MicroPython?
Owl is more 'pretty much normal python runtime ported to an ARM MCU'.
micropython is a written from scratch implementation for MCUs.
Maybe I am replying to the wrong thread here.
What could be wrong? There are probably a lot of the standard libraries which are more work to get running on micropython than Owl. Some of the language features that are already in python 2.7 are not in micropython (which is a 3.X based system).
That said, micropython is a fantastic project. I have a micropython board and also have it running in the ESP8266 with my own C modules. The whole framework is very well thought out and a pleasure to work with. It's not the python I use in my day job but I don't actually care as I have more C than python anyway :)
Just to clarify facts - Owl is PyMite (aka python-on-a-chip) fork (e.g. https://bitbucket.org/ricearch/embeddedpython/src/e491720236... , and there're dozens of PyMite references in Owl codebase), and pretty shallow fork at 46 commits past the initial import (over 2 years). PyMite has pretty long list of features not implemented, starting with standard Python exceptions. In other words, PyMite isn't exactly Python, it's Python-like language. It's very unlikely that PyMite is able to run more or less sizable script written for standard Python. (I'd love to stand corrected!)
MicroPython OTOH implements complete Python execution model (but e.g. only subset of Python object model), and nowadays runs pretty large subset of Python standard library (https://github.com/micropython/micropython-lib).
Btw, if you run MicroPython on ESP8266, please consider contributing to the mainline - this port slowed down lately due to lack of contributions. Thanks!
MicroPython OTOH implements complete Python execution model (but e.g. only subset of Python object model), and nowadays runs pretty large subset of Python standard library (https://github.com/micropython/micropython-lib).
Btw, if you run MicroPython on ESP8266, please consider contributing to the mainline - this port slowed down lately due to lack of contributions. Thanks!
I put pulls in but it seems they don't want to accept stuff that does not work like the rest of the platforms supported. Perfectly reasonable I think but the fact that there is not a way to set the wifi mode in micropython is a bit slack. They didn't want that most recent pull of mine. I'll put my whole interrupt driven framework on a fork on an share it in case anyone is interested.
I see. Well, I hope that indeed can be understood - merging code to mainline which is known as requiring a rework means breaking some people's code later. In this situation, maintaining a fork till more momentum is gathered and issues are resolved does make a sense. But please keep in touch (e.g. via MicroPython forum) - alone knowing that you keep working on it and it does work for you is a good motivation for other folks to not drop the ball with this port (and for new folks to pick it up).
I can perfectly understand why changes would not be wanted. It's no big deal at all.
That's said. The project vastly underestimates the impact the ESP8266 has had and will have. IMHO that chip and those that follow in its footsteps will revolutionize the industry in more ways than the 100 STM32 projects ever did. It's more like the Aduino viral like impact on hobbyists. As much as it's a flakey POS, it's not as pathetic as the ATMEL chips and I'm jumping on the bandwagon.
> changes would not be wanted.
Changes are wanted - very much. But clean changes adhering to MicroPython coding standards. So, if you have time and/or need to support ESP8266, please keep sending patches and working on elaborating them. In the meantime, more people appear to want to work on STM, TI and other chips, however you or me may find it strange. Probably because those chips already have been having impact on the industry - for number of last several years, and ESP8266 yet to show that impact.
All in all, MicroPython embraces ESP8266 and actually was one of the first open-source projects to provide initial support for it (nodemcu was closed-source at that time). Contributions are welcome. We're also looking for sponsorship opportunities to provide top-notch support for it, but so far it didn't work out.
Changes are wanted - very much. But clean changes adhering to MicroPython coding standards. So, if you have time and/or need to support ESP8266, please keep sending patches and working on elaborating them. In the meantime, more people appear to want to work on STM, TI and other chips, however you or me may find it strange. Probably because those chips already have been having impact on the industry - for number of last several years, and ESP8266 yet to show that impact.
All in all, MicroPython embraces ESP8266 and actually was one of the first open-source projects to provide initial support for it (nodemcu was closed-source at that time). Contributions are welcome. We're also looking for sponsorship opportunities to provide top-notch support for it, but so far it didn't work out.
In that paper they added "a small set of extension"(3KB of code) to OWL[1]. Those extensions, together with a special hardware bridging mechanism enable using the actor model in an mcu context.
Why use the actor model ? because it brings, to event
[1]OWL seems pretty similar to micro python - but they started working on it before micro python was availble.
Why use the actor model ? because it brings, to event
[1]OWL seems pretty similar to micro python - but they started working on it before micro python was availble.
This seems neat. Did it ship?
We use PyMite at work, (Python 2.x) which works pretty well. The longer you use it, the more things you find that aren't implemented, though. No int() or float(), no try except, longs don't exist at all, no keyword arguments, etc etc. You give up a lot to fit in 55 kilobytes.
Feel free to give MicroPython a try - it currently scales down to 77K (ARM Thumb2), but that includes compiler (i.e. you can start it and type Python source to execute - no "compilation" step is necessary).
If you want to hear a good interview with the developer:
http://podcastinit.podbean.com/e/episode-15-damien-george-ta...
http://podcastinit.podbean.com/e/episode-15-damien-george-ta...
[1]https://www.usenix.org/system/files/conference/atc14/atc14-p...