

MicroPython 1.4.5 - pfalcon
https://mail.python.org/pipermail/python-announce-list/2015-August/010865.html

======
minthd
For those interested in simplified embedded development , this[1] paper
implemented a python like language on microcontrollers , that does include the
actor model, and they show it enables higher abstraction(and reuse) in
microcontroller systems - which are usually event driven.

[1][https://www.usenix.org/system/files/conference/atc14/atc14-p...](https://www.usenix.org/system/files/conference/atc14/atc14-paper-
barr.pdf)

~~~
pekk
What's wrong with MicroPython?

~~~
mianos
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 :)

~~~
pfalcon
Just to clarify facts - Owl is PyMite (aka python-on-a-chip) fork (e.g.
[https://bitbucket.org/ricearch/embeddedpython/src/e491720236...](https://bitbucket.org/ricearch/embeddedpython/src/e491720236242b057991efe60e1e19cf174e7778/src/vm/obj.h?at=default#obj.h-230)
, 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](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!

~~~
mianos
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.

~~~
pfalcon
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).

~~~
mianos
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.

~~~
pfalcon
> 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.

------
sbierwagen
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.

~~~
pfalcon
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).

------
616c
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-talks-to-us-
about-micropython/)

