3 ms·
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
by 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 agoWe 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.