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

Visible keys standardization #4744

Merged
merged 6 commits into from Oct 4, 2017

Conversation

Projects
None yet
6 participants
@dannon
Member

dannon commented Oct 3, 2017

Branched from #4743 to include @mvdbeek's changes. This standardizes dict_*_visible_keys to a list everywhere, which will prevent errors like #4742 from happening.

mvdbeek and others added some commits Oct 3, 2017

@galaxybot galaxybot added this to the 18.01 milestone Oct 3, 2017

@nsoranzo

This comment has been minimized.

Member

nsoranzo commented Oct 3, 2017

I'm -0.0 on this, seems a bit a over-reaction. Tuples seem the right data type for this.

@dannon

This comment has been minimized.

Member

dannon commented Oct 3, 2017

@nsoranzo We have a mix of the two, causing confusion in how they should be handled right now (and bugs). You do agree they need to be standardized, right?

My preference for standardizing on list is simply in ease of use, and less complexity in the codebase. Currently people either have to remember to use a tuple and define it with the hacky ('element',), or we could add type checking to the consuming function(s -- one right now, but if we add any others, that's even more effort) -- but that seemed an even worse option.

I do think that we should standardize these and it's my thinking that lists are both simpler to work with now, and simpler to expect others to work with years down the road, at no real cost.

edit: There are also other places in the code that expect these to be lists, and concatenate them with other lists, etc. -- I think the expectation people have is that they can just treat these like lists, and I don't see any benefit to forcing them all to tuples.

@jmchilton

This comment has been minimized.

Member

jmchilton commented Oct 4, 2017

I agreed with @nsoranzo but @dannon is right about us using these as lists - I've done that myself now that I think about it - so I'm persuaded from a -0 to a +1 on this.

@martenson martenson merged commit c478716 into galaxyproject:dev Oct 4, 2017

6 checks passed

api test Build finished. 297 tests run, 4 skipped, 0 failed.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
framework test Build finished. 161 tests run, 0 skipped, 0 failed.
Details
integration test Build finished. 46 tests run, 0 skipped, 0 failed.
Details
lgtm analysis: JavaScript No alert changes
Details
toolshed test Build finished. 579 tests run, 0 skipped, 0 failed.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment