Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge in upstream MicroPython changes #2999

Closed
tannewt opened this issue Jun 2, 2020 · 10 comments · Fixed by #4749
Closed

Merge in upstream MicroPython changes #2999

tannewt opened this issue Jun 2, 2020 · 10 comments · Fixed by #4749

Comments

@tannewt
Copy link
Member

tannewt commented Jun 2, 2020

No description provided.

@tannewt tannewt added this to the Long term milestone Jun 2, 2020
@tannewt tannewt mentioned this issue Jun 2, 2020
@theacodes
Copy link
Collaborator

A small bump on this, as it's something I'd really love to see happen.

Notable things that we'd get:

  • Type annotations (PEP 526).
  • Walrus assignment operator (PEP 572).
  • Matrix multiplication @ operator (PEP 465).
  • Underscored numeric literals (PEP 515).
  • Support for dynamically loading native modules in mpy files.
  • Numerous code size improvements.
  • Significantly better native code emitter.

I don't presently have the time (or expertise) to do this myself, but I would be interested in sponsoring this.

@dhalbert
Copy link
Collaborator

dhalbert commented Jul 8, 2020

I am willing to do this when I have time. We are thinking of waiting for the MicroPython 1.13 release.

@benetherington
Copy link

Bump from me too!

MicroPython 1.13 was released in September, and the walrus assignment operator is very handy for tidy code.

@timonsku
Copy link

+1 on this from me, being able to write native modules without needing to integrate with the core would be huge.

@timonsku
Copy link

See https://github.com/pimoroni/pimoroni-pico/tree/main/micropython/modules for a use case for this. This probably ties also into #2825

@deshipu
Copy link

deshipu commented Feb 15, 2021

@timonsku having been through the process of trying to use that, I have to say it's not as useful as it seems. The problem is that all the functions you are going to call have to be included in a special table at compile time — and only a handful is there by default — so while it's useful for speeding up some purely computational functions, it's very limited otherwise.

@tannewt
Copy link
Member Author

tannewt commented Feb 16, 2021

I'm also very concerned about the support burden of native modules that work for ARM but not xtensa or risc-v for example. I'd encourage folks to write native modules in the core instead. We're happy to have them.

@garethhcoleman
Copy link

Is this separate issue still valuable alongside #4280?

@tannewt
Copy link
Member Author

tannewt commented Mar 2, 2021

Is this separate issue still valuable alongside #4280?

Ya, I think so. Issues can live when inactive and PRs should be closed when they are. We can close this when the 1.14 merge is done.

@ladyada
Copy link
Member

ladyada commented May 13, 2021

nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants