Re:Exposing Python 3.6's Private Dict Version
by m_mueller on Wednesday May 31, 2017 @09:38PM
(#14457336)
I don't get your point about unpacking yet to be honest. Both your code examples work fine with namedtuples I think. Adding additional attributes is better in the second example, which is why it is to be preferred, but that works with namedtuples as far as I understand.
Re:Exposing Python 3.6's Private Dict Version
by maxerickson on Wednesday May 31, 2017 @09:47PM
(#14457367)
Adding a member to the tuple requires updating all code that unpacks it.
Adding an attribute doesn't impact any code that doesn't use the attribute.
Re:Exposing Python 3.6's Private Dict Version
by m_mueller on Wednesday May 31, 2017 @10:10PM
(#14457439)
Yes, that's why you usually don't use unpacking for a namedtuple. This works just fine without me adding additional 3rd party packages:
> from collections import namedtuple
> Point = namedtuple('Point', ['x', 'y'])
> points = [Point(3,4), Point(5,2)]
> for p in points:
> print(p.x, p.y)
I think organizing / refactoring a bunch of named tuples would be a mess. In one code base I maintain I switched a bunch of namedtuples to attrs classes and the code instantly became more readable / maintainable.
The downside to the namedtuple is that it's a tuple and can be unpacked as one.
for x, y in points: print x, y
# vs.
for p in points: print p.x, p.y
# ... now go and add a z to the point class and see what happens to your code.