Tweak stickler config: ignore Python files in the docs & disable fixer

[shoyer]

It doesn't always make sense to lint these files fully.

[stickler-ci]

W1619 division w/o future statement

[stickler-ci]

W1619 division w/o future statement

[fmaussion]

Maybe we should turn off the fixer also?

[shoyer]

I would like to disable the fixer (which appears to use autopep8) entirely, for several reasons:

1. It enforces a very strict style automatically, e.g., removing spaces around arithmetic operators. This actually goes beyond PEP8, which suggests "Use your own judgment". I would rather have comments that I can tell a contributor to ignore and easily disable in the future (via the flake8 config).
2. The need to pull changes to a pull-request branch from GitHub is a surprising and somewhat disruptive.
3. I can't figure out how to disable the fixer from only some files.

[shoyer]

Maybe we should turn off the fixer also?

I'm not sure if you were suggesting turning it off entirely or only for the docs... but as I wrote above, I don't like it either.

[fmaussion]

I would like to disable the fixer (which appears to use autopep8) entirely

Yes, totally, stickler should NOT try to fix anything.

Would you like to turn off stickler entirely or just the auto-fixer? I'm fine with both: while I thinks it's nice to have a tool pointing out pep8 errors (I don't like to do it as a reviewer, it makes me feel like nit-picking), I also find it quite noisy and not very encouraging to submit PRs at an early "quick n dirty" stage, where you really shouldn't care about pep8...

[shoyer]

I also find it quite noisy and not very encouraging to submit PRs at an early "quick n dirty" stage, where you really shouldn't care about pep8...

I agree, but the alternative is to get a failed build error, and it can be a pain to dig through the Travis-CI to find out what went wrong. We use automated comments like this at work to enforce style, and on the whole I think they're probably a good thing.

I would certainly encourage contributors not to worry about these errors until they think their code is ready to submit.