5 ms·
Then you have stuff like point[0] and point[1] littered throughout your code, or you write getter functions and then you have function calls as an overhead whic
by anaphor 13y ago
Then you have stuff like point[0] and point[1] littered throughout your code, or you write getter functions and then you have function calls as an overhead which is roughly as expensive as the class. An instance of namedtuple is actually the Correct (tm) solution.
- wcummings 13y agoYou can pull the values out with de-constructive assignment, as well, which is a little nicer: (x, y) = your_fun() Not sure how this performs comparatively, I'm not much of a python programmer, I didn't realize namedtuples were a thing (TIL)
- Redoubts 13y ago>An instance of namedtuple is actually the Correct (tm) solution. Do you have an implementation to support that? Because a comment from TFA shows that's actually the worst idea in cpython. http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/#comment-1242618646 http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r...
- anaphor 13y agoSorry, which comment are you referring to? All I see is a footnote saying "One would be right to argue that collections.namedtuple() is even closer to C struct than this. Let’s not overcomplicate things, however. The point I’m trying to make is valid regardless" which doesn't really say it's a bad idea, just that he didn't decide to talk about it in that article.
- rectangletangle 13y agoSomething along the lines of <x, y = point> would be a little cleaner than directly referencing the indexes. This technique can also be used in a loop <for x, y in [(0, 1), (23, 41)]: print(x, y)>.