-
Notifications
You must be signed in to change notification settings - Fork 87
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
RFE: subscriptable properties #107
Labels
Comments
jonathanunderwood
changed the title
RFE: subscriptable objects
RFE: subscriptable properties
May 31, 2022
MSAdministrator
added
enhancement
New feature or request
help wanted
Extra attention is needed
labels
Jun 6, 2022
@MSAdministrator am happy to provide an implementation of this, but want to avoid taking a direction that wouldn't be acceptable. Here's my current thinking:
WDYT of this implementation direction? |
@jonathanunderwood Yeah that would be awesome and I like this approach as well. I would wait until #111 is merged though |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Is your feature request related to a problem? Please describe.
When I am using this library I find myself doing a lot of this sort of thing:
or
etc. And similar for other lists of objects. I am aware of the ability to search, but that's quite heavy weight when I mainly just want to be able to subscript based on ATT&CK ID.
Describe the solution you'd like
It would be really helpful if the collection properties were subscriptable as well as iterable.
Describe alternatives you've considered
This is technically fairly simple to implement if we just wanted to return a dict instead of a list, breaking the old API. Personally, I'd be fine with that, but others probably have a different view.
So, the question is, does the existing iterable nature of these properties need to be preserved? And if so, how comfortable are you with breaking the existing API?
Options I can think of:
subscriptable=False
keyword argument to theAttck()
constructor, which whenTrue
returns properties as dicts rather than lists. This maintains the existing API, but isn't particularly pythonic, as functions return types depending on arguments of a constructor is a undiscoverable pattern, and also makes reasoning about types difficult (for future use of type hinting)There may be others.
Add any other context or screenshots about the feature request here.
Note that since Python 3.7 insertion into dicts maintains order. Also note that the IndexedOrderedDict from the
indexed
package enables really fast index based lookups.The text was updated successfully, but these errors were encountered: