That's not how you typically program in C - there, a buffer is usually allocated, knowing upper bound of data chunk size, or just using arbitrary, but realistically high enough, bound, and then operations are performed as much as possible using pointers within this buffer, and inplace operations. Surely, C way is gazillion of times faster, and not less importantly, memory-friendly.
For MicroPython, it is important to strive for the highest possible efficiency, so it would be tempting to support such programming model. Let's figure out how to do that.
Problem #1: Getting data into buffers
Python over time grew datatypes suitable for C-like inplace buffer operations. That's obviously bytearray (and array.array for cases of greater-than-byte unit of data). The problem is how to get data from outside into bytearrary with minimum of copies (specifically, zero).
If one doesn't know Python API well, one would consider to read bytes object from a stream, and then convert to bytearray. But the latter operation means copying. So, one would consider adding an operation to convert a bytes object to bytearray inplace. But that's completely non-Pythonic way, and thus immediately gets "ugly" moniker. Implementation-wise, bytes and bytearray are rather different objects, so there's no guarantee that such "inplace" conversion will happen without copying (or will be possible at all, if underlying structures need to grow, which is very likely with mutable growable type).
But looking at API reference, Python has that covered - it has methods to read data directly to an arbitrary mutable buffer (including, but not limited, to bytearray). For stream protocol, that's method readinto(). But if some type has multiple means to read data, this leads to noticeable API bloat. This can be seen with socket type, which has also recv() and recv_from() methods. Thus, we get recv_into() and recv_from_into() (note also arguably inconsistent naming - but it's governed by "recv_from" case, surely "recv_frominto" would be ugly).
So, API bloat. Conceptually, problem is solved - Python has it already, so we have little choice but follow that trend. But of course, implementation-wise, adding extra methods has its overhead, so there's always concern about adding "rarely" used one. Well, the solution should be along the lines we discuss - they should be used often!
Problem #2: In-place operations on buffers
First of all, besides literally "inplace" (modifying) operations, another useful operation class is analog of C "pointing" operations. That subclass is well served with memoryview object - it's possible to take a light-weight slice of a bytearray object, which will be essentially represented by offset and length values.
That still leaves real in-place string operations on bytearrays, like for example "strip". And when I started to write them, I thought they're not supported. Live and learn: https://docs.python.org/3.4/library/std ... es-methods:
So, cool! Python rules, as usual! We just need to implement this wealthDue to the common use of ASCII text as the basis for binary protocols, bytes and bytearray objects provide almost all methods found on text strings, with the exceptions of: [few methods]
Comments, further ideas?