Option flags

[ghost]

Cleanup, adds test

1. Renamed is_rate_limited to sleep_if_needed to better clarify
   behavior
2. Extract rate limiting error to a module constant
3. Add test suite and required dependencies
   Run 'nosetests' from your virtual environment to see it in action
4. Wrapped long lines

[ghost]

I looked at the changes and think it is good for now. I would wait to move the option parsing into its own function until some additional changes are made.

I would like to handle the flags differently so that we don't have to maintain two lists - one being the parameter provided to add_argument and the other being the strings in the list of tuples used to check for the flags. I'm thinking it might make sense to build a little object to hold this information.

On the other hand, it seems like a common problem so I wonder if there's some better way of using the argparse module that I'm missing 😆

[0xmilan]

I would leave the if (anyTrue and anyFalse) check so people at least get notified when they try to do --user-list --no-s3-scan --link-scan, and to avoid unexpected behaviour.

[0xmilan]

https://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse
This is the best thing I found for the parameter handling. Also, there's parser.add_mutually_exclusive_group(required=False) which should protect against command --feature --no-feature, if we want that.

But this doesn't solve the problem of having to maintain two lists, and no doubt there's a better way of doing that than what I put together quickly.

[emtunc]

Hello @influenza ! Thank you for the PR - wondering if it would be a good idea to separate out testing to a separate branch? My knowledge is very limited in this area but it feels odd introducing dependencies (in requirements.txt) that won't be used by most/any of the users of the tool?

Are you able to join the public Slack Workspace I set up? Not an issue if you can't but wanted to discuss some testing integrations I was playing with earlier today.

[ghost]

That makes a lot of sense actually. I'll pop into the slack later on. Thanks!

…

On Thu, Jan 10, 2019, 19:04 Mikail Tunç ***@***.*** wrote: Hello @influenza <https://github.com/influenza> ! Thank you for the PR - wondering if it would be a good idea to separate out testing to a separate branch? My knowledge is very limited in this area but it feels odd introducing dependencies (in requirements.txt) that won't be used by most/any of the users of the tool? Are you able to join the public Slack Workspace I set up? Not an issue if you can't but wanted to discuss some testing integrations I was playing with earlier today. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvCw_E9Z2PqMjHcGR04Gnuj25MwCXZFks5vB9UcgaJpZM4Z6WID> .