[Question] What is main difference between MicroPython and Pycopy ?

[redradist]

I am curious what is main difference between MicroPython and Pycopy in terms of syntax support, underlining run-time behaviors and so on

As we know MicroPython not support complete Python syntax and have some issue with it sometimes:
http://docs.micropython.org/en/latest/genrst/syntax.html?highlight=syntax

Also there are inheritance issue (different implementation details):
micropython/micropython#6077

All it split Python ecosystem and enforce to implement two different libraries in Pure-Python and with support MicroPython ...

I am wondering how all this topics relate to Pycopy ?

[pfalcon]

Well, this is very wide and open-ended question, at least for me. Answering to the question in the subject, the biggest difference between MicroPython and Pycopy is paradigmatic. For me, MicroPython is just an older project I worked on some time ago. As MicroPython didn't have clear enough paradigm/didn't follow written down paradigm closely, and I couldn't resolve those issues in bounds of MicroPython, I just went ahead with a separate project instead.

• Pycopy tries to stick to whatever written in https://github.com/pfalcon/pycopy/blob/master/README.md, https://github.com/pfalcon/pycopy/blob/master/CONTRIBUTING.md, https://github.com/pfalcon/pycopy/wiki/ContributorGuidelines .
• Pycopy is by definition a Python subset and dialect. (Fairly speaking, like any other Python implementation, e.g. CPython itself doesn't implement all the features available in other implementations).
• The dialect of Python which Pycopy implements is "a generic object-oriented language with elements of functional programming".
• Pycopy develops in 2 orthogonal directions: 1) develop (largely done by now, in stabilization phase) the minimalist "core" of the Pycopy language; 2) develop flexible extensibility mechanism, which would allow to achieve greater compatibility with other dialects of Python languages, e.g. CPython.

All other differences stem from this approach.

I am curious what is main difference between MicroPython and Pycopy in terms of syntax support, underlining run-time behaviors and so on

A generic answer: Pycopy can do most things that MicroPython can, with improvements and fixes. The goal of Pycopy is to be a fast language and support JIT, so some features which will interfere with that are excluded. If you have interest in specific features, feel free to ask.

As we know MicroPython not support complete Python syntax and have some issue with it sometimes:
http://docs.micropython.org/en/latest/genrst/syntax.html?highlight=syntax

What specific issues do you face with what specific software? I ported various Python projects to Pycopy, and before that, to MicroPython, and for well-written projects, that's pretty easy. The whole situation is not much different than porting e.g. Python2 project to Python3, or CPython3.8 project to CPython3.5.

Also there are inheritance issue (different implementation details):
micropython/micropython#6077

If you mean compliant support for multiple inheritance, then I consider it an issue too, and have a prototype implementation in the "devel" branch of Pycopy.

All it split Python ecosystem and enforce to implement two different libraries in Pure-Python and with support MicroPython ...

As mentioned above, the situation is not much different than CPython3.6 with CPython3.5, or Python2 or Python3 situation. And beyond that, there're different languages too, just consider that some library can be available in Erlang or JavaScript.

But Pycopy actually has a paradigmatic solution to the problem above. No, you don't need to implement two different libraries for CPython and Pycopy (then more different libraries for PyPy, Jython, IronPython, etc.). You just need to implement it for Pycopy, and then use on CPython or any other implementation. Because while making Pycopy fully compatible to CPython isn't really a goal (well, if you know who will fund that, let me know), CPython compatibility with Pycopy is the stated goal of the project: https://github.com/pfalcon/pycopy-lib#cpython-backports .

[redradist]

@pfalcon

Pycopy is by definition a Python subset and dialect. (Fairly speaking, like any other Python implementation, e.g. CPython itself doesn't implement all the features available in other implementations).

What do you mean that CPython itself doesn't implement all the features ?
CPython could be considered as reference implementation as it supports all features

Pycopy develops in 2 orthogonal directions: 1) develop (largely done by now, in stabilization phase) the minimalist "core" of the Pycopy language; 2) develop flexible extensibility mechanism, which would allow to achieve greater compatibility with other dialects of Python languages, e.g. CPython.

I like this two statements !!
This approach is similar to Rust with its libcore and libstd
Recently I have started discussion about modularization to achieve the same goal, but faced with misunderstanding in community

I am curious what is main difference between MicroPython and Pycopy in terms of syntax support, underlining run-time behaviors and so on

A generic answer: Pycopy can do most things that MicroPython can, with improvements and fixes. The goal of Pycopy is to be a fast language and support JIT, so some features which will interfere with that are excluded. If you have interest in specific features, feel free to ask.

You mentioned that Pycopy supports JIT as PyPy did !!
Does it mean that current Pycopy implementation is much faster than CPython ?

Also there are inheritance issue (different implementation details):
micropython/micropython#6077

If you mean compliant support for multiple inheritance, then I consider it an issue too, and have a prototype implementation in the "devel" branch of Pycopy.

Yes, I mean multiple inheritance and MRO (Method Resolution Order (MRO) is not compliant with CPython) and it is cool that you are working on it !!
Is there test branch or how to experiment with it right now ?

All it split Python ecosystem and enforce to implement two different libraries in Pure-Python and with support MicroPython ...

As mentioned above, the situation is not much different than CPython3.6 with CPython3.5, or Python2 or Python3 situation. And beyond that, there're different languages too, just consider that some library can be available in Erlang or JavaScript.

But, why not support all syntax of CPython anyway ?
I can understood the run-time behavior, because different implementation have different goals ... but syntax ...

[pfalcon]

What do you mean that CPython itself doesn't implement all the features ?

E.g. it doesn't implement features of Stackless Python: https://github.com/stackless-dev/stackless

CPython could be considered as reference implementation as it supports all features

Exactly, it's a baseline, boring, inefficient Python implementation.

Recently I have started discussion about modularization to achieve the same goal, but faced with misunderstanding in community

Python is a very popular language with vast community. It's impossible to satisfy everyone in it. The only solution is just embrace the situation that there're many dialects and implementations of Python, and let each cover its niche (while still letting Python users to switch easily from one to another). In this regard, I treat CPython itself as just a particular Python dialect. Neither MicroPython nor Pycopy try to displace it, they try to bring Python to places where previously it couldn't reach.

You mentioned that Pycopy supports JIT as PyPy did !!

MicroPython supports very simple, unoptimized JIT (on modern "desktop" CPUs it's actually slower than bytecode VM). Pycopy inherits this support from MicroPython. This JIT is implemented in (IMHO) poor and scalable. I would like (as time permits) to work on better JIT.

Does it mean that current Pycopy implementation is much faster than CPython ?

No, but it's much simpler, and will stay that way. And simplicity of the implementation is pre-requisite for fast JIT.

Yes, I mean multiple inheritance and MRO (Method Resolution Order (MRO) is not compliant with CPython) and it is cool that you are working on it !!
Is there test branch or how to experiment with it right now ?

Not as of now. It's just internal prototype. I'm still not sure how to go about it. While I'd like to support MRO for "extended" Pycopy, for "native" Pycopy, I'd like to discourage usage of multiple inheritance.

But, why not support all syntax of CPython anyway ?
I can understood the run-time behavior, because different implementation have different goals ... but syntax ...

Adding more and more features is against the idea of "core" Pycopy. However, "extended" Pycopy is all for adding "all syntax of CPython" and anything beyond it (want pattern matching in the language - go for it). To make that possible and easy, there should be pure-Python bytecode compiler. I initially wanted to part the older Python2 pure-Python compiler module: https://github.com/pfalcon/python-compiler/, but found it too bloated and embarked to write one for Pycopy from scratch: https://github.com/pfalcon/pycopy-lib/tree/master/ucompiler .

If you're interested in those matters, you're definitely welcome to drive them forward - play with them provide feedback, learn project principles and guidelines, contribute or run your project providing extensions in the directions you'd like.

[redradist]

Yes, I mean multiple inheritance and MRO (Method Resolution Order (MRO) is not compliant with CPython) and it is cool that you are working on it !!
Is there test branch or how to experiment with it right now ?

Not as of now. It's just internal prototype. I'm still not sure how to go about it. While I'd like to support MRO for "extended" Pycopy, for "native" Pycopy, I'd like to discourage usage of multiple inheritance.

I think multiple inheritance very useful (I came from C++ World) and I know one thing:

Runtime and Language should not enforce people to write code in certain way, instead they should provide consistent features that works properly

Multiple inheritance is very useful sometimes and without it requires a lot of hand writing code

[pfalcon]

I think multiple inheritance very useful (I came from C++ World)

I think that C++ is actually a "counterexample" which only proves the overall trend ("most languages do well without multiple inheritance"). To start with, C++ in statically typed language, where classes are not first-class (can't be created at runtime). Surely, if you know all the class hierarchy at compile time, you can deal somehow even with such beasts like multiple inheritance (but even then you are given extra knobs to lash it into shape with it like virtual vs non-virtual base classes). But the main thing - while C++ has multiple inheritance, it does NOT have MRO (method resolution order) - and that's what we're talking about here. If a method comes from different classes in a hierarchy, then any call to it must be explicitly specified with a prefix of the desired target class.

If you're happy with C++ way, then multiple inheritance works for you even in the current versions of Pycopy/MicroPython - just call ambiguous methods as BaseClass.method(), as in C++.

Runtime and Language should not enforce people to write code in certain way, instead they should provide consistent features that works properly

Exactly my point. There's just a notion of "generic programming language". Any software developer, and even advanced user, deals with multiple programming languages. For example, I always prototype non-trivial algorithms in Python, but then may as well rewrite it in C. In that regard, it makes sense to maintain "core functionality of programming languages", to be portable and interoperable across different languages. And things like multiple inheritance are on the fringe of it. So for example, if you write a Python library, you should not force users to use/deal with multiple inheritance, unless it's really required, which is rare.

Multiple inheritance is very useful sometimes and without it requires a lot of hand writing code

I already invited to be more specific. Are you interested to use some "big Python" library with Pycopy? It uses multiple inheritance? Let's have a look at it. Maybe the best way to use that library is in existing CPython, then wash hands after use. Instead of spending hours and hours (spread over days-weeks-months) of somebody's personal time to race to support that library in Pycopy/MicroPython.

As I said, I'm keen to support proper multiple inheritance in Pycopy, but relative priority of that depends on how much it would be really useful, as otherwise I have development backlog for years ahead.

[redradist]

I think multiple inheritance very useful (I came from C++ World)

I think that C++ is actually a "counterexample" which only proves the overall trend ("most languages do well without multiple inheritance"). To start with, C++ in statically typed language, where classes are not first-class (can't be created at runtime). Surely, if you know all the class hierarchy at compile time, you can deal somehow even with such beasts like multiple inheritance (but even then you are given extra knobs to lash it into shape with it like virtual vs non-virtual base classes). But the main thing - while C++ has multiple inheritance, it does NOT have MRO (method resolution order) - and that's what we're talking about here. If a method comes from different classes in a hierarchy, then any call to it must be explicitly specified with a prefix of the desired target class.

If you're happy with C++ way, then multiple inheritance works for you even in the current versions of Pycopy/MicroPython - just call ambiguous methods as BaseClass.method(), as in C++.

Runtime and Language should not enforce people to write code in certain way, instead they should provide consistent features that works properly

Exactly my point. There's just a notion of "generic programming language". Any software developer, and even advanced user, deals with multiple programming languages. For example, I always prototype non-trivial algorithms in Python, but then may as well rewrite it in C. In that regard, it makes sense to maintain "core functionality of programming languages", to be portable and interoperable across different languages. And things like multiple inheritance are on the fringe of it. So for example, if you write a Python library, you should not force users to use/deal with multiple inheritance, unless it's really required, which is rare.

Multiple inheritance is very useful sometimes and without it requires a lot of hand writing code

I already invited to be more specific. Are you interested to use some "big Python" library with Pycopy? It uses multiple inheritance? Let's have a look at it. Maybe the best way to use that library is in existing CPython, then wash hands after use. Instead of spending hours and hours (spread over days-weeks-months) of somebody's personal time to race to support that library in Pycopy/MicroPython.

As I said, I'm keen to support proper multiple inheritance in Pycopy, but relative priority of that depends on how much it would be really useful, as otherwise I have development backlog for years ahead.

Okay, thanks, I got your point ;)

And just weird question ... why Pycopy ?
I understood the name Pycore (like a "small" python, core functionality) ... but what does it mean Pycopy ?

You mean it could be copied everywhere ?

[pfalcon]

And just weird question ... why Pycopy ?
I understood the name Pycore (like a "small" python, core functionality) ... but what does it mean Pycopy ?

Generally, name is a name, and figuring out why something (or someone) was named like it was, doesn't make much sense. Of course, us humans love to do that nonetheless, so sure, let's chat about that too.

So, initially my fork was named just "pfalcon/micropython", and I got a suggestion from MicroPython owner that, given that's a separate project, it rather should have a different name. Given that it's a reasonable request, I followed. I didn't feel much creative about all this naming, so given that one of my concern with MicroPython was uncontrollable growth, I decided to go to "smaller" prefix. As a number of project in the ecosystem already used "pico" prefix (e.g. https://github.com/pfalcon/picoweb, https://github.com/pfalcon/picotui/), it was natural to go for "pico" either. I specifically avoided full spelling of "Python", as it's trademark of PSF, and there were already issues due to that.

All that lead to "Picopy", but that looks pretty boring, and I'm sure there's a ton of projects named like that (well, I'm sure I checked). So, to make it more original, I decided to style first "pi" as "py" either.

Yeah, that gave a strange tilt to the name, which came out, "Pycopy". I figured I like it. It's the same deeper meaning which was e.g. put in the name "GNU". As known, it "means" "GNU is Not Unix". And it's the same idea, expressed differently.

So, it's not CPython, it's not MicroPython, it's Pycopy.

[pfalcon]

Please don't close this, it definitely goes in the "something you always wanted to know, but were afraid to ask" department. I jotted down detailed answers exactly for people to be able to discover/refer to.

[chimobb]

Thanks very helpful.
Using Micropython mostly on Stm32 and Esp32, and any comments from you is welcome.