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

Add locus_tag to GraphicRecord by default #46

Closed
wants to merge 3 commits into from
Closed

Add locus_tag to GraphicRecord by default #46

wants to merge 3 commits into from

Conversation

MrTomRod
Copy link
Contributor

I found locus_tag to be a useful property of GraphicFeature objects because it tends to be unique.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 91.508% when pulling cbe2b96 on MrTomRod:master into 6ace5cd on Edinburgh-Genome-Foundry:master.

@Zulko
Copy link
Member

Zulko commented Oct 12, 2020

My two cents: the GraphicFeature's primary parameters all refer to graphic properties ("what you will see") and the locus_tag parameter, if it is not used for graphical display, would be an outlier. If you simply don't add the locus_tag as a parameter in the definition GraphicFeature (the rest of your code remaining unchanged) the locus_tag would then be interpreted as a **data component and be accessible via my_feature.data['locus_tag'].

@MrTomRod
Copy link
Contributor Author

That makes sense, I didn't study the API closely enough. Thanks!

@MrTomRod MrTomRod closed this Oct 12, 2020
@Zulko
Copy link
Member

Zulko commented Oct 12, 2020

To clarify, I wasn't suggesting to close the MR, as parts of it like compute_locus_tag may still be a valid approach. You can re-open this MR if you believe a core change to DFV is best way to solve your problem.

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

Successfully merging this pull request may close these issues.

None yet

3 participants