[Python-ideas] recorarray: a mutable alternative to namedtuple

[Andrew Barnert]

On Mar 27, 2015, at 06:22, Joao S. O. Bueno <jsbueno at python.org.br> wrote:
> 
> On 27 March 2015 at 01:40, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
>> But how is being "an array of objects" any different from what a tuple,
>> list, array.array, bytearray, bytes, str, etc. already are? What's
>> specifically array-like about this type as opposed to all of those? And
>> what's specifically record-like about your type compared to namedtuple,
>> Struct, or SimpleNamespace?
> 
> Acutally, on my understanding, the request on this thread is for
> something that is quite concrete,
> existing in other languages, and that can be done in Python in a few
> lines, but is not in
> the stdlib:
> 
> The Python equivalent of a C Struct.

But a C struct is not a subtype of, or substitutable for, a C array. It's not indexable. And the same is true with the equivalents in other languages. In fact, the dichotomy between struct--heterogeneous collection of fixed named fields--and array--homogeneous collection of indexed fields--goes back way before C. So, if you want the equivalent of a C struct, there's no reason to make it an iterable in Python.

And a class already is the Python of a C struct, it's just that it can do _more_ than a C struct. A language like C++ that wants to share code and values with C has to bend over backward to make it possible to write a C++ struct (or class) that doesn't use any of its extra features and is therefore exactly equivalent to a C struct, but Python has no need for that. (Except when you actually do want to share values with C code--but for that case, we've got ctypes.Struct, which is exactly what you want in that situation.)

> Just that.
> An easy to create class, with named fields,

Which is easy to do: just create a class, and create its fields in the __init__ method (or, in some cases, it's acceptable to use class attributes as "default values" for instance attributes).

>  with possible
> type-enforcement for those fields.

Of course namedtuple doesn't have type-enforcement for the fields.

I'm not sure whether you're talking about MyPy static type checking, or runtime checking, but either way, it's easier to add onto a regular class than to a namedtuple-like class factory.

> Or maybe it _does_ exist in Python, and it is a matter of having a
> nice example in the docs:
> for example a "blank" class with "__slots__"  would do it.

A blank class without __slots__ can also do it. There are times when __slots__ are useful, but usually you're fine with just a plain __dict__. Encouraging people to use it when they have no need for it just because it's more like idiomatic C would be a bad idea. (It's like encouraging people to use @property to get something more like idiomatic .NET or ObjC, when actually they should just be writing idiomatic Python and using attributes directly.)

> Or a blank class with slots that could serialize and deserialize
> itself to a sequence
> in a seamless way.

Why do you want to serialize and deserialize to a sequence? A C struct can't do that, and neither can equivalent types in other languages.

> class Base:
>   __slots__ = ()
>   def __init__(self, seq=None):
>       if not seq: return
>       for attr, val in zip(self.slots, seq):
>            setattr(self, attr, val)
>   def __iter__(self):
>       for attr in self.__slots__:
>           yield getattr(self, attr)
> 
> 
> def NamedList(name, fields):
>   ... # split string with space separated fields, and other niceities here
>   return type(name, (Base,), dict(__slots__=fields))
> 
> And 10-15 more lines if one wants type-checking, default values,
> __repr__ into that.

Default values and __repr__ are _also_ not part of a C struct. So, again, if what you're looking for is the equivalent of a C struct, you can replace all of the above with:

    def Base: pass

If you want other features that C structs don't have, then yes, you may have to write them, but the same is true in C (and, in fact, it's clumsier and more difficult in C).

> Ithink getting a proper recipe for this, and
> publicizing it on the documentation ecosystem is enough  - maybe a
> Pypi module adding some more goodies - and if that would get any
> traction - the usual consideration for inclusion could apply.