This PR removes the Elite and EliteBatch namedtuples from the public API; instead, we create an Elite and EliteBatch namedtuple on the fly in each archive. This allows us to support custom field names in each namedtuple in the future.
In creating this PR, I was considering whether to create a custom namedtuple for each archive (when the archive is constructed, similar to how pandas has itertuples), or to use a dict. These were the pros and cons I came up with of dicts over such namedtuples:
Pros:
This is clearly backwards-incompatible, so users will know something has broken. The old tuple unpacking behavior will definitely not work here, and calling the attributes also will not work.
Dicts are less finicky than namedtuples, in that there are no attributes to manage.
Dicts are already a common data structure; people already know how to get the keys etc
It is easier to handle retrieving just a couple of fields. In such a case, we can just add the required keys to the dict. In contrast, we would have to set some fields to None in a namedtuple
We no longer will have a name conflict with the index method of namedtuples
Cons:
The old unpacking logic will no longer work
Getting attributes will no longer work
Harder to tell which things are batch because it’s not in the name, although I think it’s usually clear from the context
TODO
[x] Replace all usages
[x] Double check for usage of Elite and EliteBatch
Description
This PR removes the Elite and EliteBatch namedtuples from the public API; instead, we create an Elite and EliteBatch namedtuple on the fly in each archive. This allows us to support custom field names in each namedtuple in the future.
In creating this PR, I was considering whether to create a custom namedtuple for each archive (when the archive is constructed, similar to how pandas has itertuples), or to use a dict. These were the pros and cons I came up with of dicts over such namedtuples:
Pros:
Cons:
TODO
Questions
Status
yapfpytestpylintHISTORY.md