It seems like the python maintainers always try to complicate things for themselves to cater for some obscure use case that nobody use. I mean really, when was the last time you ever accessed a namedtuple by index?? (For vectors i do see a benefit that you can throw it right into a matrix multiplication that is designed for arrays but really, you can do that equally easy in other ways). And constructing them on the fly doesn't make much sense either as it defats the benefits of a shared type across the code base.

All people ever wanted was just a way to write in one line ´Point3D = struct(x, y, z)´ that translates into the exact equivalent of:

    class Point3D: 
        def __init__(x, y, z):
            self.x = x
            self.y = y
            self.z = z

What would be the startup performance of parsing the above 5 line class compared to a namedtuple? Surely it should be faster to create it with a shorthand form built into the language, if the functionality is equivalent?

danpalmer

> I mean really, when was the last time you ever accessed a namedtuple by index?

Yesterday. I use this quite a bit. I like non-named tuples as a data structure and use them regularly, and often partially upgrade a tuple to a named tuple.

Changing these sorts of things is what caused the Python 2/3 split, I don't think we as a community want that again for a while, so backwards compatibility for things like this that aren't _that_ uncommon should be a priority.

hyperbovine

Agreed, I use the fact that "namedtuples are tuples" constantly. For one thing, you can pass them to 3rd party libraries that take tuples while maintaining readability on your end. I would be horrified if they dropped index access. It would break everything.

I should say though, for simple POJO-style classes @attr.s (https://github.com/python-attrs/attrs) has replaced 90% of my namedtuple usage.