3 ms·

There are plenty of issues with the stdlib. Part of it don't respect the PEP8, there are inconsistencies with argument types and orders, some of it is even unus

There are plenty of issues with the stdlib. Part of it don't respect the PEP8, there are inconsistencies with argument types and orders, some of it is even unusable for real life usages (ex: csv in python 2.7) and we keep it for legacy reasons. The fact is, the use cases you are showing are wrong, and the one I'm talking about are the proper ones. It's ok to make mistakes, we all do a lot of them. And we will have to pay for those. If you are interested in the subject, last month we had a huge debate on the Python mailing list about a way to have a proper official immutable but non interable structured record to replace named tuple and avoid those abuses. And also to maybe include something like attrs in the stdlib.

eesmith 9y ago
It would be nice if you could show me a proper example, as what you wrote doesn't match with my understanding of how it is used nor with how it should be used. My argument is to resist the temptation to use namedtuple for anything except a migration from tuples to named attributes. While there is some overlap with what you wrote, they are not the same. I would like to know what I'm missing.
- sametmax 9y ago
  A proper use for namedtuple: @property def coordinates(): x = self.calculateX() y = self.calculateY() return x, y this could become: Point = namedtuple('Point', ('x', 'y')) @property def coordinates(): x = self.calculateX() y = self.calculateY() return Point(x, y) It stays compatible with the previous implementation. as you can still do: x, y = stuff.coordinates But now can do: point = stuff.coordinates point.x The same example apply for a row a from timeseries in a database or a line of stats in a csv. But now imagine you have a response from a ldap server returning a list of authorized person. You could manipulate those persons in a dictionary. Some people may want to have a nicer way to access them, with the look up syntax. You can be tempted to use a namedtuple here, but that make no sense, as a person is not iterable. The alternative is to use empty class, but it's very verbose. But now you can use types.SimpleNameSpace: >>> class Person(types.SimpleNamespace): pass >>> p = Person(name='foo', age=12) # no __init__ to write >>> p # free repr Person(age=12, name='foo') >>> p.age # nice access syntax 12 The good thing is that if you ever need to extend Person to later have a more complex behavior, you can just do so as it's a regular class. The bad things are: - you may need something immutable - you may want some checks done to restrict the attributes used Which is why currently people abuse namedtuple. We don't have a good story for those. Hence the debate on the mailing list. Nevertheless, it's good to remember that the Python community has a philosophy of "we are all consenting adults here" and a good track record for following it. immutability and attributes restrictions are not definitive show stoppers in Python, and SimpleNameSpace is a decent solution while waiting a purer to come up.
  - eesmith 9y ago
    Your example with Point() is exactly what I said was a good use case, for apparently the same reasons why I said it was a good use case. I said "'namedtuple' has one good use - migration from a tuple object to a real object while allowing backwards compatability to the tuple API. ... It's also fine if it will only be used by code where you have full control over its use and can either prevent inappropriate API use ... Otherwise, don't use it." You replied "Only if one is misusing namedtuple". I interpreted this as an objection to my use guidelines. From what I can tell, you are in complete agreement with me.

eesmith 9y ago

It would be nice if you could show me a proper example, as what you wrote doesn't match with my understanding of how it is used nor with how it should be used. My argument is to resist the temptation to use namedtuple for anything except a migration from tuples to named attributes. While there is some overlap with what you wrote, they are not the same. I would like to know what I'm missing.

sametmax 9y ago
A proper use for namedtuple: @property def coordinates(): x = self.calculateX() y = self.calculateY() return x, y this could become: Point = namedtuple('Point', ('x', 'y')) @property def coordinates(): x = self.calculateX() y = self.calculateY() return Point(x, y) It stays compatible with the previous implementation. as you can still do: x, y = stuff.coordinates But now can do: point = stuff.coordinates point.x The same example apply for a row a from timeseries in a database or a line of stats in a csv. But now imagine you have a response from a ldap server returning a list of authorized person. You could manipulate those persons in a dictionary. Some people may want to have a nicer way to access them, with the look up syntax. You can be tempted to use a namedtuple here, but that make no sense, as a person is not iterable. The alternative is to use empty class, but it's very verbose. But now you can use types.SimpleNameSpace: >>> class Person(types.SimpleNamespace): pass >>> p = Person(name='foo', age=12) # no __init__ to write >>> p # free repr Person(age=12, name='foo') >>> p.age # nice access syntax 12 The good thing is that if you ever need to extend Person to later have a more complex behavior, you can just do so as it's a regular class. The bad things are: - you may need something immutable - you may want some checks done to restrict the attributes used Which is why currently people abuse namedtuple. We don't have a good story for those. Hence the debate on the mailing list. Nevertheless, it's good to remember that the Python community has a philosophy of "we are all consenting adults here" and a good track record for following it. immutability and attributes restrictions are not definitive show stoppers in Python, and SimpleNameSpace is a decent solution while waiting a purer to come up.
- eesmith 9y ago
  Your example with Point() is exactly what I said was a good use case, for apparently the same reasons why I said it was a good use case. I said "'namedtuple' has one good use - migration from a tuple object to a real object while allowing backwards compatability to the tuple API. ... It's also fine if it will only be used by code where you have full control over its use and can either prevent inappropriate API use ... Otherwise, don't use it." You replied "Only if one is misusing namedtuple". I interpreted this as an objection to my use guidelines. From what I can tell, you are in complete agreement with me.