Editable strings anyone?

[John Machin]

Brian Kelley <bkelley at wi.mit.edu> wrote in message news:<3C72C074.306 at wi.mit.edu>...
> John Machin wrote:
> > You'll find one nuisance when working with 'c' arrays; it doesn't
> > support coercing an ordinary string to an array -- you have to do it
> > yourself.
> 
> I encountered the same problem and of course the solution was subclass 
> array.array!  Unfortunately, array.array can't be subclassed.  (Python 
> 2.2)  In fact, I found arraymodule.c very confusing in this respect.
>
[snip] 
> 
> What would it take to make array.array or array.ArrayType an acceptable 
> base type for subclassing?

Not all built-in types can be subclassed. The brochure promises
"subtyping of *selected* built-in types" [my emphasis]. The array type
is probably not classified as built-in anyway.

Quite simple, the array type is not set up to be subclassed.

If one was desperate to subclass the array type, one would need to
read the brochure (PEP 253 (Subtyping Built-in Types)) especially the
section headed "Preparing a type for subtyping", and do what it says
-- I would suggest heavy plagiarism from listobject.c.

One might like to, while one has the lid off arraymodule.c, fix it so
that the original problem is solved at source without the need to
subclass -- for several methods that involve an "other" argument,
simply allow "other" to be an itera{ble|tor} [or maybe just a sequence
if one was worried about speed] that delivers objects that the array
object can contain.

Noting that array.array is short of a few methods (like sort), it
might be worth the effort to refactor array and list so that
list(["x", 42, 0.05]) was just a special case of array i.e.
array.array('O', ["x", 42, 0.05]) and as far as possible all the list
methods and all the care and attention that has gone into list
(sorting, intelligent growth when appending, etc) could apply to
arrays as well. Any volunteers?