On Mar 26, 2015, at 21:08, Joonas Liik firstname.lastname@example.org 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 email@example.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 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.