Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Row should be dict not list #158

Open
saulshanabrook opened this issue Jul 15, 2014 · 3 comments
Open

Row should be dict not list #158

saulshanabrook opened this issue Jul 15, 2014 · 3 comments

Comments

@saulshanabrook
Copy link

Would it make sense for rows to behave like dictionaries instead of lists? I would love to be able to do key based field retrieval, instead of index based.

@iurisilvio
Copy link
Collaborator

I like this idea, but it requires some internal changes. Row doesn't know anything about headers, but it is a reasonable change.

We can't remove index based support, so it should work both ways.

@DanielDisisto
Copy link

DanielDisisto commented Aug 16, 2017

PR #268 looks like a great solution, and for me at least would make tablib much more useful. Is this being considered for merge? Given the change to Dataset.__getitem__ return type, I understand this is not a simple decision to make, but I think it would be beneficial.

If the change is considered too breaking, how about leaving __getitem__ return a tuple as currently does, but adding a Dataset.get_row(i) which returns the Row instance (just to prevent having to access Dataset._data directly)? It's a bit clunky, but avoids all backward-compatibility issues while still providing a way to access row data by column name.

EDIT: I'd somehow missed the fact that getting a specific item on the table by row index & column name can already be achieved with Dataset.dict[row][column_name]. The only issue I have with that is that it is quite expensive to do this repeatedly, running the _package() method each time it's accessed to rebuild the entire dict.

@ms8r
Copy link

ms8r commented Aug 27, 2017

Good point - I think we could get around the breaking issue in #268 by placing the logic of #268 behind the Dataset.dict API (less expensive than running _package each time) while continuing to return tuples for plain vanilla __getitem__ access. Will be a few weeks until I have some time for this again but will look into amending #268.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants