Skip to content

Enable MICROPY_PY_ARRAY_SLICE_ASSIGN on SAMD21 #193

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

Closed
deshipu opened this issue Aug 16, 2017 · 3 comments
Closed

Enable MICROPY_PY_ARRAY_SLICE_ASSIGN on SAMD21 #193

deshipu opened this issue Aug 16, 2017 · 3 comments
Assignees
Milestone

Comments

@deshipu
Copy link

deshipu commented Aug 16, 2017

The following code:

a = bytearray(b'abc')
a[1:2] = b'123'

works just fine on MicroPython and CircuitPython on the ESP8266, but fails with

TypeError: 'bytearray' object does not support item assignment

on the M0 boards. This is the fastest way to copy a fragment of a byte array (since it uses memcpy in C), but since it doesn't work consistently on all ports, I can't use it in my libraries. It would be nice if all ports supported it.

@tannewt tannewt added this to the Long term milestone Aug 21, 2017
@dhalbert
Copy link
Collaborator

dhalbert commented Sep 20, 2017

Turning on MICROPY_PY_ARRAY_SLICE_ASSIGN takes something like 384 to 576 bytes to include. I got different measurements based on trying to remove it from the Express build or add it to the non-Express build. It's a pretty Pythonic feature, and I think we could squeeze it in by lowering -finline-limit and/or seeing how big things are after the ASF4 port.

@gpshead
Copy link

gpshead commented Oct 30, 2017

I just noticed that this feature was missing on the non-express builds as I tried migrating some code to a smaller board. I'd love to see it there. If ultimately not, would it be possible to update the error message?

Currently it was something along the lines of Error: bytearray index assignment not supported. (paraphrased, my uc isn't connected at the moment). This was confusing as this isn't index assignment, it is slice assignment. But even improving the error message would consume more string space...

The workaround for a common case is a (presumably slow) manual loop:

Before:

a[start:end] = data

After:

# Assuming len(data) == end-start.
# Does not deal with expanding bytearray a if end-start would go beyond its bounds.
k = start
for b in data:
  a[k] = b
  k += 1

If you could even support just the case of slice assignment into a preallocated fixed buffer without reallocation/resizing that would be fine for my use case (I generally try to avoid reallocs)

@dhalbert
Copy link
Collaborator

Current measurements say this costs 400 bytes. I guess I'd choose those over #384 (add .decode) if I had to choose just one because it's more awkward without it. As with #384, we need to consider our storage budget in future releases.

@tannewt tannewt assigned tannewt and unassigned dhalbert Oct 31, 2017
dhalbert pushed a commit that referenced this issue Nov 1, 2017
This costs 376 bytes on a Trinket M0 leaving 33412 bytes free.

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

No branches or pull requests

4 participants