Terry J. Reedy added the comment:
[Raymond, I am assuming that you only left this open for additional comments,
possibly more favorable than yours. If I am wrong, reopen.]
I have not read the namedtuple doc before. I did so now and think the Point
example is fine for the purpose of explaining namedtuples and should be left as
is. It is clear to me and should be for anyone.
For instance, it naturally leads to this example.
"Subclassing is not useful for adding new, stored fields. Instead, simply
create a new named tuple type from the _fields attribute:
>>> Point3D = namedtuple('Point3D', Point._fields + ('z',))"
While I do not consider the issue of 'practice' to be entirely relevant here, I
note that complex numbers only work for 2-d points while tuples work for other
dimensions, as the above shows. Tuples can be easily multiplied by a
transformation matrix of the same dimension through indexing. The namedtuple
factory just creates a friendly facade for what is still basically a tuple.
"Named tuple instances do not have per-instance dictionaries, so they are
lightweight and require no more memory than regular tuples." Anyway, serious
numerical work is more likely to use numpy arrays or something similar.
----------
nosy: +terry.reedy
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16670>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
