-
Notifications
You must be signed in to change notification settings - Fork 668
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
Allow for more flexibility with wildcard in selections #2436
Comments
Would this be something for GSoC? Especially if one couples it to a larger overhaul of selections (see #371 and #345 (comment) to use |
This alone is way too small for GSoC. If anything, I expect it to be a nice onboarding issue. |
I'd disagree with @jbarnoud , I think this is a complicated project if we include more regex-like characters, so could be a gsoc project. It's worth keeping in mind that we've going to pass in n_atoms strings to any match function, so performance could be an issue too. |
If it comes with a selection overhaul, it is indeed a more substantial project. But limited to the wildcards, it is a matter of changing the vicinity of
|
This limited issue seems to be good issue for someone to get into it. I will add a GSoC project with a proposed rewrite of the selection system. |
Hi, I am Hsueh, Cheng-Hsun, a medical student at National Yang-Ming University in Taiwan. I am interested in the 'Improved atom selections' project in GSoC 2020. Could I work on this issue? |
We are about to publish a blog post at https://www.mdanalysis.org/blog/ with more details for GSoC. However, you're more than welcome to start working on this issue. Put up a pull request that references this issue. We can then comment and discuss there. Note that other people are still free to work on this issue if they so desire. Ultimately, we want GSoC candidates to engage with our code and us as a community and the best way is to work on some code. |
* Fixes #2436 * Selection strings changed to use fnmatch. This now allows for more flexible wildcard usage as well as for using multiple wildcards at once. * Added two new tests to match the new functionality * New doc section on wildcards * Remove test for multiple wildcards * Update in AUTHORS * Update CHANGELOG
@lilyminium with the updated wildcard matching, the section of the User Guide needs an update. I didn't require this as part of this PR (keeping it simple for GSoC). I will raise a UG issue. |
Thanks @Iv-Hristov and @orbeckst! |
Is your feature request related to a problem? Please describe.
Selections strings allow for one wildcard that will glob any number of characters. This is surprising for advanced users of selections in VMD, for instance, that allows more flexible wildcards.
Describe the solution you'd like
Ideally, there should not be a limit in the number of wildcards that can be used. Also, the wildcard characters that can be used would be
*
for an undefined number of characters,.
for one character, and?
for one or more characters.Additional context
The
fnmatch
module from the standard library implements comparisons with such wildcards: https://docs.python.org/3.8/library/fnmatch.htmlThe text was updated successfully, but these errors were encountered: