[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.