3 ms·

I disagree -- namedtuple has a crucial property that I've found incredibly useful. Namedtuples are immutable. This makes it impossible (well, not really, but h

I disagree -- namedtuple has a crucial property that I've found incredibly useful. Namedtuples are immutable. This makes it impossible (well, not really, but hard) for a namedtuple to change its state without telling me about it, because if it changes state it's not the same namedtuple any more. I agree that namedtuple being a sequence type is problematic, but deciding not to use a lightweight immutable data structure because your colleagues might use it badly is throwing out the baby with the bathwater.

eesmith 9y ago
I was not speaking of in-house software were only "your colleagues might use it badly". In that case, you have access to the entire source code and aren't so worried about backwards compatibility. I was referring to publishing a library which uses a namedtuple as part of the public API. Your argument seems to be that there are good things about namedtuple - which I agree with - so therefore I shouldn't be so dismissive of it. That might be reasonable if there were no other easy way to construct a light-weight object with immutable attributes. But the attr package exists, as js2 pointed out in a sibling branch. See http://www.attrs.org/en/stable/examples.html#immutability http://www.attrs.org/en/stable/examples.html#immutability .
- kemitche 9y ago
  If you're writing a python library, you should already be aware that there's only _so much_ you can do to prevent the library's users from using it incorrectly or oddly - this is Python after all, there's no private/protected. From that perspective, I don't see the problem with returning a namedtuple, if you document it and write your changelogs appropriately when/if you add a field.
  - eesmith 9y ago
    We must assume people are being reasonable. If someone uses a module where the top-level docstring says "not part of the public API", and which starts with an "_", then that person is not being reasonable, by well-established Python developer standards. I have no objections to breaking compatibility for people who reach into a private API. It's different if I hand them an object and say "use it". Even if I don't document anything, it's implicit that this is part of the public API. These are two different things, though yes, there can be ambiguity. "if you document it and write your changelogs appropriately when/if you add a field." I tried to point this out earlier. It takes only a few (boring) minutes to write the essentially boilerplate code. While over the lifetime of the project it will likely take more time to write the supporting documentation and deal with the effects of breaking compatibility.
- sevensor 9y ago
  I just gave attr another look -- I bounced off it before because of the cutesy naming. It's a matter of taste, but I thought it was unlikely that a library that made such a grating decision would be fun to use. My second impression is that I've got to give attr points for clarity: the implementation is short and to the point, considering how much it monkeys around with Python's classes. I can see why you'd want to use it for an API, because it won't endow an object with unwanted Sequence methods. Not an issue in my current job, but your point is well taken.
  - eesmith 9y ago
    Thanks! Personally, I suck it up and write the boring boilerplate, because I prefer to avoid dependencies and most of the things I work on are low-level. But I'm special that way. ;)
- xapata 9y ago
  I recommend avoiding the attrs module. You might save time writing, but you'll lose far more than that in reading time.

eesmith 9y ago

I was not speaking of in-house software were only "your colleagues might use it badly". In that case, you have access to the entire source code and aren't so worried about backwards compatibility. I was referring to publishing a library which uses a namedtuple as part of the public API. Your argument seems to be that there are good things about namedtuple - which I agree with - so therefore I shouldn't be so dismissive of it. That might be reasonable if there were no other easy way to construct a light-weight object with immutable attributes. But the attr package exists, as js2 pointed out in a sibling branch. See http://www.attrs.org/en/stable/examples.html#immutability http://www.attrs.org/en/stable/examples.html#immutability .

kemitche 9y ago
If you're writing a python library, you should already be aware that there's only _so much_ you can do to prevent the library's users from using it incorrectly or oddly - this is Python after all, there's no private/protected. From that perspective, I don't see the problem with returning a namedtuple, if you document it and write your changelogs appropriately when/if you add a field.
- eesmith 9y ago
  We must assume people are being reasonable. If someone uses a module where the top-level docstring says "not part of the public API", and which starts with an "_", then that person is not being reasonable, by well-established Python developer standards. I have no objections to breaking compatibility for people who reach into a private API. It's different if I hand them an object and say "use it". Even if I don't document anything, it's implicit that this is part of the public API. These are two different things, though yes, there can be ambiguity. "if you document it and write your changelogs appropriately when/if you add a field." I tried to point this out earlier. It takes only a few (boring) minutes to write the essentially boilerplate code. While over the lifetime of the project it will likely take more time to write the supporting documentation and deal with the effects of breaking compatibility.
sevensor 9y ago
I just gave attr another look -- I bounced off it before because of the cutesy naming. It's a matter of taste, but I thought it was unlikely that a library that made such a grating decision would be fun to use. My second impression is that I've got to give attr points for clarity: the implementation is short and to the point, considering how much it monkeys around with Python's classes. I can see why you'd want to use it for an API, because it won't endow an object with unwanted Sequence methods. Not an issue in my current job, but your point is well taken.
- eesmith 9y ago
  Thanks! Personally, I suck it up and write the boring boilerplate, because I prefer to avoid dependencies and most of the things I work on are low-level. But I'm special that way. ;)
xapata 9y ago
I recommend avoiding the attrs module. You might save time writing, but you'll lose far more than that in reading time.