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

Moved here the pylint tools of abacus. #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

motty-stratoscale
Copy link
Contributor

I also changed abacus' rc file a bit: disable bare-except and broad-except.

I also changed abacus' rc file a bit: disabled bare-except and broad-except.
shutil.rmtree(tempDir)

parser = argparse.ArgumentParser(description='pylint zipped files or single python files')
parser.add_argument('--zip', dest="zipfiles", default=[], action='append', help='zip file with source:relative package path to verify inside zip file (e.g. strato)')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

replace --zip --file and --dir with automatic detection of type (name.endswith('.zip') and os.isdir())

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you add nargs='*' you can type
--files a.py b.py c.py
or
--files *.py
instead of
--file a.py --file b.py --file c.py

@segev-lior
Copy link
Contributor

IMHO bare-except and broad-except should not be excluded - they are bad practice. If you really want them, take the trouble to type pylint: disable=

@motty-stratoscale
Copy link
Contributor Author

@lior-stratoscale, I think that bare/broad excepts are okay: 1. people that write them know what they do; 2. I wonder how often there is really a specific case to handle, vs the common "log and raise" or "just don't die" cases.

About the other changes, when time permits...

@segev-lior
Copy link
Contributor

and another thing: why is this in its own repo?
we do need a common repo, but IMHO it should be called something more general (strato-tools?) so we can put other things in it as well

@motty-stratoscale
Copy link
Contributor Author

strato-pylint already exists, and promoted by Pavel.
I hope he's okay with it that I moved "competitor" tools into it.

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.

2 participants