Pycopy – a minimalist and memory-efficient Python implementation
github.com
github.com
As far as I'm aware pycopy has a better async implementation. Micropython probably has a bit wider adoption. A lot of libraries are compatible with both, but ymmv
Another notable fork of Micropython is Circuitpython which is maintained by Adafruit.
I wish ada was more available for microcontrollers.
https://github.com/micropython/micropython/pull/5332
(Though there have been some additional performance improvements since that was merged.)
The improvements to the old implementation are significant.
I am no longer interested in following pycopy's progress but I'd be shocked if the asyncio implementation was better. Happy to see measurements to suggest otherwise...
Just reading from that PR micropython now also runs picoweb, which is an async webframework that runs on an esp32 and I believe even on an esp8266
Well, I was the author of "uasyncio" module, as was used with MicroPython. When I switched to Pycopy, I took that module with me.
> The improvements to the old implementation are significant.
Well, how to put it. Before I wrote uasyncio, I wrote asyncio_slow. And before I wrote that, I watched dozens of people writing their own async frameworks for Python. And I watch dozens of people doing the same as we speak. The reason I embarked to write my piece is because I wasn't satisfied with how other people do it. I may imagine you feel the same. So, good luck. (If you do it right, I'll use your stuff.)
> but I'd be shocked if the asyncio implementation was better
It's better, where "better" defined as "more minimalist". If you're not interested in minimalism, then you as well can use CPython's asyncio (and CPython itself).
> I no longer contribute to upstream directly, due to upstream's failure to recognize me as a major contributor and uphold my copyright accordingly.
The context is an analogy to Common Lisp versus Scheme. Common Lisp was a massive programming system. Scheme is simple enough that one could embed into anything, and many systems did just that.
I don't think you'd use Pycopy to write a desktop or cloud application (CPython would be the tool for that). You would add it to an existing desktop application to e.g. allow it to be scripted.
Disclaimer: I'm intentionally muddling languages, implementations, etc. to keep this at six understandable sentences, rather than an essay. Yes, I'm aware that emacs used Common Lisp for scripting, that MIT Scheme is super-high performance, and so on. That's not the point of this post.
That's pretty much it in my opinion. There's a huge difference in available libraries. Yet for simple things and special cases there still might be reasons to choose MicroPython over CPython even on desktop platforms. CPython startup time is a multiple of MicroPython startup time for instance (ok, not a lot of chance that matters, but you never know) and some things are more performant (but others arent; due to optimizing for size). I initially got to know it when looking for an embeddable scripting language working on unix/windows and intime which is a real-time extension for Windows, and of all major and less major implementations I checked MicroPython was the only one which only needed a small amount of extra code to make it compile, because it was written from the start with the idea to use C99 and make no assumptions about availability of libraries. CPython on the other hand was pretty messy (and LUA, and ...) E.g. if CPython sees an msvc compiler it automatically assumes it's running on Windows and has access to the complete CRT. Of which intime is the prime example where that is not the case. So, not easy to workaround and moreover it assumes e.g. it has registry access and that's not something which can be disabled with PP directives. And so on. I'm not really blaming anyone for that, makes sense from a certain point of view, but it's not too ideal. MicroPython on the other hand has like a hundred PP directives making a lot of features configurable, even language features so it can be made really minimal. Also MicroPython's source code overall is really nicely written, very readable, again in contradiction to some of CPython's source I've seen. And some parts like interpreter and compiler are pretty genius.
Believe it or not, but that's one of the messages the Pycopy project tries to convey: Software can be simple. And understandable. And you really can write a useful (at least to yourself) application which can run both on your desktop, on your router with 2MB memory, on a microcontroller board, or in a cloud.
Some more info about this "human-scale computing" idea is here: https://www.blog.pythonlibrary.org/2020/02/10/pydev-of-the-w... .
I remember old good days, when each software project wanted to rule the world ;-).
There's a nice blog on what Arm did for micro:bit on this:
https://community.arm.com/education-hub/b/rob-leeman/posts/b...
https://github.com/micropython/micropython/tree/master/ports...
But it doesn't provide much more than the basic REPL.
You could also try MicroPython on Unicorn, where more of the hardware is simulated in the browser:
http://micropython.org/unicorn/ https://github.com/micropython/micropython-unicorn
The Unicron-MicroPython kernel is quite old but it's still useful for getting a feel for what's possible.
Has the author ever used Scheme or Common Lisp? They are fundamentally different (incompatible) dialects of Lisp. Is this really a fitting comparison?
So yes, please take that comparison as going from one Lisper to another. (Which likely means we'll be yelling at each other over "fundamental differences!111".)
In my head, it sounds it would be an easier task to do, since it would still let the C compiler do a lot of the work.
This ideas seem to make sense, but I have no experience with writing parser and dealing with language stuff, and I'm afraid that in practice it might be a bad idea.
The goal being to have a scripting language that is fast to parse, easy to write and runs quickly.
If you wouldn't like to repeat what many people before did, but would like to do something (potentially) new, feel free to accept my "challenge": https://old.reddit.com/r/Compilers/comments/grfjrb/challenge...
I'm kind of curious how one would do {loop,if} statements without introducing jumps and/or phi nodes?
If you're interested in this stuff, I'd suggest to comment on Github/Reddit.
Yeah, for sure.
Been (slowly) poking at a JavaScript 3rd Edition grammar which I have the parser and AST built for so now the next logical step is to get the SSA form implemented. Been reading through "Combining Analyses, Combining Optimizations" (and friends) so think that's the route I'm taking since I kind of like Futamura projections as a theory and it seems to fit in well with that.
Really need to get over my shorn yak fetish (rewritten my asdl generator like 3 times already) and crack down on this thing but c'est la vie...
The last para sounds like you are looking for freepascal - fast parsing, easy to write, blazing fast execution.
My interest for Pycopy is exactly to work on more advanced JIT, etc. techniques, and that's one of the reason for the fork - I want to keep the foundation clean and simple enough (yet extensible). "Simple" is the foundation for "fast JIT" (because if you have to much stuff to check for, the result code will be slow).
That said, I have C3 MRO (i.e. full multiple inheritance support) in the devel branch. Metaclasses, I leave to upstream (they've got to do something useful too), at least until I need them (none so far: "generic language", remember? How will I port those metaclasses to C++? Python is certainly not the only language I use). inspect.stack - no go, CPython implementation detail.
In other words, things like interfacing with C++ is somewhat outside of Pycopy scope. But they very well may be in the scope of MicroPython project (and if they're available for MicroPython, they should be also usable for Pycopy, as 2 projects are largely compatible.)
the million dollar question: does it have GIL?