[Python-ideas] namedtuple is not as good as it should be

[Ryan Hiebert]

A namedtuple as an easy class has been great. But the way that I had figured namedtuple would work before I figured out how it actually worked was that it would just create it at instantiation. So, there would be no namedtuple template, just a call like this:

point = namedtuple(x=1, y=0)

And then access could be, in addition to point[0] and point[1], point.x and point.y

Since then, with the discussion about using an ordereddict for kwargs, I've realized that that wouldn't be possible, because there wouldn't be a way to get the order of these arguments. But, if it did work, it would make sense that a simple subclass of (my version of a) namedtuple could easily serve the purpose of how namedtuple is constructed, which is to name the fields once, rather than on instantiation. I see also issues with coercing tuples or other sequences to namedtuples using that method, since my ideas for that involve using keyword arguments, but that would mean something different already.

As an aside, even though I know why -- because it would require using a list or real tuple to make a namedtuple instance -- it's been weird coercing a tuple into a namedtuple, because it doesn't use the typical convention that passing a sequence into the constructor makes a namedtuple with that sequence. For example, I'd expected this would work like coercion to a list:

>>> Point = namedtuple('Point', 'x y')
>>> coordinates = (1,0)
>>> point = Point(coordinates)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __new__() missing 1 required positional argument: 'y'
>>> point = Point(*coordinates)
>>> point
Point(x=1, y=0)
>>> list(coordinates)
[1, 0]

I'm not sure how much value I've added to the conversation, but these are the views of someone who just started actually using namedtuples.

Ryan


On Jun 9, 2013, at 9:06 PM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:

> 
> On Jun 9, 2013, at 5:55 PM, Christian Tismer <tismer at stackless.com> wrote:
> 
>> If it is necessary to have class instances like today, ok. But there is no
>> need to search that class in a pickle! Instead, the defining set of attributes
>> could be pickled (uniquely stored by tuple comparison), and the class could
>> be re-created on-the-fly at unpickling time.
> 
> That is a reasonable wish :-)
> But, I'm not sure how you propose for it to work.
> What would you expect from:
> 
> >>> Soldier = namedtuple('Soldier', ['name', 'rank', 'serial_number'])
> >>> johnny = Soldier('John Doe', 'Private', 12345)
> >>> roger = Soldier('Roger', 'Corporal', 67890)
> >>> fireteam = [johnny, roger]
> >>> pickletools.dis(pickle.dumps(fireteam))
> 
> Would it re-specify the class for every instance (at a cost of both speed and space)?
> 
>    [(nametuple, 'Soldier', ['name', 'rank', 'serial_number'], ('John Doe', 'Private', 12345)),
>     (nametuple, 'Soldier', ['name', 'rank', 'serial_number'], ('Roger', 'Corporal', 67890))]
> 
> Or would you have a mechanism to specify the names just once?
> 
>    [(nametuple, 'Soldier', ['name', 'rank', 'serial_number'])
>     (Soldier, ('John Doe', 'Private', 12345)),
>     (Soldier, ('Roger', 'Corporal', 67890))]
> 
> What would you do with a customized named tuples?
> 
> >>> class PrettySoldier(Soldier):
>         def __repr__(self):
>               return 'N:{0} R:{1} S:{2}'.format(*self)
> 
> How about enumerations?  To pickle the value, Color.red, would you propose
> for that instance to store the definition of the enumeration as well as its value?
> 
> 
> 
> Raymond
> 
> 
> P.S.  This was supposed to be part of my previous email, but I had to board a flight.
> 
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130609/0066efd9/attachment.bin>