
Pycopy – a minimalist and memory-efficient Python implementation - BiteCode_dev
https://github.com/pfalcon/pycopy
======
tda
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.

~~~
matt_trentini
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:

[https://github.com/micropython/micropython/pull/5332](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...

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

------
mcstafford
I'm a bit of a hermit at times, but this smells like "doesn't play well with
others":

> I no longer contribute to upstream directly, due to upstream's failure to
> recognize me as a major contributor and uphold my copyright accordingly.

[https://github.com/pfalcon/pycopy#fork-
faq](https://github.com/pfalcon/pycopy#fork-faq)

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

------
beshrkayali
"Good for desktop, cloud, constrained systems, microcontrollers, and just
everything." might be a tad overambitious...

~~~
murgindrag
I read this as "embeds anywhere."

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.

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

Some more info about this "human-scale computing" idea is here:
[https://www.blog.pythonlibrary.org/2020/02/10/pydev-of-
the-w...](https://www.blog.pythonlibrary.org/2020/02/10/pydev-of-the-week-
paul-sokolovsky/) .

------
mathgenius
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?

~~~
jaustin
You can with the MicroPython project that this was forked from, but not
necessarily with mainline yet, depending on what behaviour you want.
[https://github.com/micropython/micropython/issues/3474](https://github.com/micropython/micropython/issues/3474)
[https://github.com/micropython/micropython/issues/888](https://github.com/micropython/micropython/issues/888)

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://community.arm.com/education-hub/b/rob-
leeman/posts/building-a-micro-bit-simulator)

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

~~~
pfalcon
Believe or not, but there's sad irony that it can be "pronounced" both ways
;-).

------
globular-toast
> Pycopy to CPython is a similar thing as Scheme to Common Lisp.

Has the author ever used Scheme or Common Lisp? They are fundamentally
different (incompatible) dialects of Lisp. Is this really a fitting
comparison?

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

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

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

~~~
pfalcon
Welcome to the club (of Python compiler writers):
[https://github.com/pfalcon/awesome-python-
compilers](https://github.com/pfalcon/awesome-python-compilers)

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...](https://old.reddit.com/r/Compilers/comments/grfjrb/challenge_for_all_proganalysis_hackers_and/)

~~~
UncleEntity
> In particular, prove or disprove that this can be done without introducing
> additional "goto" statements.

I'm kind of curious how one would do {loop,if} statements without introducing
jumps and/or phi nodes?

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

~~~
UncleEntity
> If you're interested in this stuff...

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

------
tom_mellior
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?

~~~
andyjpb
'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.'

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

------
bwasti
would a library like pybind (for C++ extensions) be compatible with the
philosophy of this python implementation?

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

------
est
> Select ports have support for _thread module (multithreading)

the million dollar question: does it have GIL?

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

------
jononor
Another fork of micropython? We already have circuitpython. Maybe more?

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

