Good to know: pycopy is a fork of micropython. The maintainer of pycopy was the second most contributor to micropython, but at somepoint he decided to fork micropython as there were some disagreements.
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.
It used to be true that pycopy had some minor improvements over MicroPython's asyncio module. But, recently, the MicroPython asyncio module has been completely overhauled, most of the details are captured here:
(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...
> pycopy had some minor improvements over MicroPython's asyncio module
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 haven't followed the recent developments, last time I managed to compile pycopy was end of last year. Would be nice to read about a recent comparison between the two. Is there any reason to prefer one over the other?
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
I once targeted ARM/Win32 with freepascal, and was surprised that it got compiled. It even loaded the com objects necessary to build platform user interfaces (barcode reader stuff and showing menus). The problem was, it had dozens of subtle bugs like not bubbling up certain exceptions, maths rounding errors and I simply didn't have the time to fix or report them so I gave up. It probably got better over time but the experience stuck with me and I don't recommend the tool for professional use.
Fair enough, I only use it for basic things on the desktop. I'm not fluent enough in Pascal, and it seems like there's not enough resources out there to make my life easier. Plus nobody pays me to use it, so it's low on my list of tools.
I wonder if the OP could address this point and also give some more context on why he "lost commit access to the main repository". I think it could be useful to make a more informed opinion on the two projects (other than the different goals).
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.
> I don't think you'd use Pycopy to write a desktop or cloud application
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.
I read this as "embeds anywhere. ... I don't think you'd use Pycopy to write a desktop application
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.
I wonder if you could hit this with emscripten and then run it in a browser. There are other CPython's that have been compiled to webasm, but this one might be more light-weight. Maybe?
I just realized that the name is probably pronounced "pyco py" instead of "py copy". I spent most of the day thinking that the name didn't make any sense.
Yes, I'm of that generation which (being student age) drooled over Lisp (in all its possible dialects), just the same as the current generation drools over Haskell or whatever.
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".)
As a member of the current generation, I can confirm that no one drools over Haskell except hardcore nerds. We drool at Go and Rust and new JS frameworks. And Python I guess, but everyone loves Python.
I still have the idea of writing some kind of a "transpiler" that translate a pythonic language into C. Preferably typed, with sets, dicts and arrays.
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.
SSA is entirely about phi nodes. Otherwise, the page at the link above shows an "if" statement without goto's. And if you follow more links there, you'll see a "while" without goto's too.
If you're interested in this stuff, I'd suggest to comment on Github/Reddit.
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...
Could someone in the know explain how Pycopy/MicroPython code is executed? I don't understand whether these are (bytecode) interpreters or compilers to machine code. Or are they both?
'Pycopy can execute scripts in textual source form or from precompiled bytecode, in both cases either from an on-device filesystem or "frozen" into the executable.'
Thanks, but this doesn't answer the question how it executes those scripts. I would usually interpret it to mean a bytecode interpreter, but as the sister comment explains, that would not be the full story since there is indeed native code compilation as well.
They're both. All that stuff comes from MicroPython for full disclosure. There's a bytecode VM and a rather primitive JIT. Such primitive that actually on modern designed-for-meltdown processors, bytecode VM actually runs faster than the JIT.
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).
No, I implement a generic object-oriented language with elements of functional paradigm, amenable for small-size VM and JIT implementation, a Python dialect. Extensibility is also important goal, but of course, extensibility and JITtability conflict, so you get ('ll get) one or another.
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.
I'm not sure. My interest is in "Python first" approach, after all, the whole idea of developing a small Python implementation (first MicroPython, then Pycopy) was to write code in Python, not C/C++. Where interfacing with existing libraries is required, the best way to do that is again from Python side, using FFI (https://pycopy.readthedocs.io/en/latest/library/ffi.html). That however usually means code written in C, as C has a simple and stable enough ABI to which it's easy to interface.
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.)
Pycopy inherits threading support from MicroPython (I'm an async/coroutine guy, you know). And MicroPython can be compiled without GIL (but handling locks for your data structures is all yours then).
Look at github - there're 3.4K forks of MicroPython. The only difference of this one is that it's by the guy who wrote ~30% of MicroPython (so if you use MicroPython, you likely rely on a bunch of stuff written by me), and who continue whatever didn't fit into MicroPython in a fresh project. Whether that's a lot or not is up to you to decide (I definitely had enough of ideas to go with a fork.)
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.