[issue16670] class Point in collections.namedtuples may be not that good example
New submission from julien tayon: Priority: low Keywords: documentation After watching http://www.youtube.com/watch?v=o9pEzgHorH0 (Stop writing classes by diedrich) I think the class Point example for the named tuples may be a wrong practice: http://docs.python.org/2/library/collections.html#collections.namedtuple Since complex basic types 1* does the same, (if x is real and y is imag) 2* does more (rotation, norms, symbolic notation with i) At my opnion pointing some code to http://bugs.python.org/issue1818 (if it is accepted) may be the case of use of the named tuple. ---------- assignee: docs@python components: Documentation messages: 177382 nosy: docs@python, julien.tayon priority: normal severity: normal status: open title: [docs] class Point in collections.namedtuples may be not that good example versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Raymond Hettinger added the comment: I like the current example. It does a great job teaching people how namedtuples work. Also, I think you've drawn the wrong conclusions from Jack's talk. ---------- assignee: docs@python -> rhettinger nosy: +jackdied, rhettinger priority: normal -> low _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Changes by Éric Araujo <merwok@netwok.org>: ---------- nosy: +eric.araujo title: [docs] class Point in collections.namedtuples may be not that good example -> Point class may be not be a good example for namedtuple versions: +Python 3.4 -Python 2.6, Python 3.1 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Andrew Svetlov added the comment: +1 for leaving the doc as is ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
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 <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Raymond Hettinger added the comment: I like the current example. It does a great job teaching people how namedtuples work. Also, I think you've drawn the wrong conclusions from Jack's talk. ---------- assignee: docs@python -> rhettinger nosy: +jackdied, rhettinger priority: normal -> low _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Changes by Éric Araujo <merwok@netwok.org>: ---------- nosy: +eric.araujo title: [docs] class Point in collections.namedtuples may be not that good example -> Point class may be not be a good example for namedtuple versions: +Python 3.4 -Python 2.6, Python 3.1 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
Andrew Svetlov added the comment: +1 for leaving the doc as is ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
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 <report@bugs.python.org> <http://bugs.python.org/issue16670> _______________________________________
participants (5)
-
Andrew Svetlov -
julien tayon
-
Raymond Hettinger
-
Terry J. Reedy
-
Éric Araujo