On Thu, 22 May 2008, Bruce Leban wrote:
Tuples are immutable. Lists are mutable. The reason I suggest making it variable length is so that it supports the full list semantics and you could for example create a NamedList object with no values and then add values to it (ditto for NamedDict).
I might be wrong here, but I think one of the reasons NamedTuple was decided upon (its immutability, specifically) was a performance issue. It's a lot easier to optimize a struct when you know exactly what its fields are. I think making a mutable one of these is really not offering all that much advantage to anyone in a large number of cases.
Well, I think the "Named" aspect is important. For example, repr(x) tells you the name. I can tell if two objects are the same type.
Well, right. That's the point of a struct-style class. You name it whatever you would like.
Also the NamedDict supports attribute access to the specific fields you've declared and no others. So it's not a freewheeling object that you can add any attribute to it. It's just a lightweight way to create an object backed by a dict (just as NamedTuple is).
I'm confused. I thought you said you wanted mutability. Now you can only have the fieldnames you specify in the beginning? This is not really how a dict usually operates. That said, you can mess with __slots__ all you want in your free time, but I think we're straying pretty far from "one obvious way" here. -- Cheers, Leif