Skip to content

Enable MICROPY_PY_ARRAY_SLICE_ASSIGN on SAMD21 #193

Closed

Description

@deshipu

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.

Activity

  1. added this to the Long term milestone on Aug 21, 2017
  2. dhalbert commented on Sep 20, 2017

    @dhalbert
    Collaborator

    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.

  3. modified the milestones: Long term, 3.0, 3.0 Beta on Sep 25, 2017
  4. gpshead commented on Oct 30, 2017

    @gpshead

    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)

  5. dhalbert commented on Oct 31, 2017

    @dhalbert
    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.

  6. assigned and unassigned on Oct 31, 2017
  7. added a commit that references this issue on Nov 1, 2017
    15dcc70
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions