On Mar 26, 2015, at 21:08, Joonas Liik <liik.joonas@gmail.com> wrote:

namedlist perhaps? :)

if you want:"namedtuple, but mutable. " then namedlist seems like the obvious alternative..

But, as discussed earlier in the thread, a list isn't right, or at least isn't obviously right, because lists can change size, and what would it mean for a namedlist to, say, delete element 3?

And that's really the problem: Python's entire infrastructure is designed around things which are reshapable like lists, or immutable like tuples, and this doesn't fit either one.

On 26 March 2015 at 07:17, Zaur Shibzukhov <szport@gmail.com> wrote:

вторник, 17 марта 2015 г., 19:52:28 UTC+3 пользователь Luciano Ramalho написал:
Sometimes we need a simple class to hold some mutable attributes,
provide a nice repr, support == for testing, and support iterable
unpacking, so you can write:

>>> p = Point(3, 4)
>>> x, y = p

That's very much like the classes built by namedtuple, but mutable.

I propose we add to the collections module another class factory. I am
calling it plainclass, but perhaps we can think of a better name. Here
is how it would be used:

>>> import collections
>>> Point = collections.plainclass('Point', 'x y')

The signature of the plainclass function would be exactly the same as
namedtuple, supporting the same alternative ways of naming the
attributes.

There is an attempt to make such alternative: recordarray

The name "array" seems really unfortunate. It doesn't give you any clue that this thing is halfway between a tuple and a list. Also, we've already got a bytearray, array.array, and the NumPy array types, all of which hold homogeneous simple-value types and can be accessed as buffers. And bytearray and array.array are resizable. And np.ndarray--like a C array, in effect--returns views when sliced rather than copies. Just about everything this name implies is misleading.

And as for recordarray, that doesn't exactly scream "like a namedtuple, but with array instead of tuple".

Also, in the weeks this thing has been discussed, no one has yet come up with a use case where. Look at the motivating example, Point--do you think location[2] meaning the same thing as location.z is a good thing? That's neither easy nor common in C and its OO descendants, or SmallTalk and its, or most other languages, and I can't remember ever being bothered by that.

The best anyone has come up with is that it might be more space-efficient than a SimpleNamespace or a standard __slots__ class, for all those times when you really need a billion points and can afford to needlessly waste 140 bytes per point instead of 12, but can't afford to waste 188.