Hello, I'm trying to set up my build system to use pylintrc files during the build. For example, in my pylintrc file I was going to do something like:
``` disable=all enable=E disable=import-error ``` Which (of course) doesn't work: ``` $>pylint --rcfile=pylintrc my_file.py <stacktrace truncated> backports.configparser.DuplicateOptionError: While reading from 'pylintrc' [line 24]: option u'disable' in section u'MESSAGES CONTROL' already exists ``` Once I realised that they are INI files, it made more sense. INI files do not allow for multiple values for a key (within a section), and different parsers handle this case differently. Since strict=True was being used by the Python parser, it raise this exception. The annoying part is that you can pass multiple 'enable/disable' arguments on the command line. In fact, there is an example in the documentation auto-generated by `pylint --generate-rcfile`: "If you want to run only the classes checker, but have no Warning level messages displayed, use '--disable=all --enable=classes --disable=W'" But this cannot be done in the pylintrc file. Annoying, since I was not going to use the command line and changing my build system to do would be non-trivial. I would like to see the pylintrc file have at least as much capability as the command line. I would like to propose to extend the syntax to provide an ordering. Proposal: Today we have "disable" and "enable", with "enable" taking precedent. Perhaps we could change the syntax to be "disableX" "enableY", with X and Y being positive integers. Higher precedence would be determined by higher integers. "enable" would still have precedent within a given integer level. It would be backwards compatible, with 'disable' being an alias for 'disable1' and 'enable' being an alias for 'enable1'. Some examples: ``` disable=all enable=classes disable2=W ``` would be equivalent to: ``` disable1=all enable1=classes disable2=W ``` There could easily be a better way to do that this, or some pattern/syntax people already use when dealing with INI files in order to work around this. I would like to see the pylintrc file have at least as much capability as the command line. Let me know what you think, Michael Overmeyer
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
