It’s been working like a champ. I can easily tell who is non-compliant and who is with a single glance. And I very much appreciate the code being “the company’s” not “my style”.
I loved black until their double quote requirement. There’s a lot of discussion and they have a rationale. But hitting that shift key is too much work for me and my projects.
It’s funny that I like the idea of a right, opinionated way but am faced with the reality that finding the right right way is really tough.
I would use them if there was a single quote config setting (or they switched to single quotes, obviously).
I use precommit to run Black and I’ve gotten used to staging my files, adding them to an empty message commit (which aborts it after running black if no changes and aborts the commit if there are changes) before I stage files for the actual commit I want to send out.
It’s a bit annoying from time to time but I marvel at how… uniform and not “my code” it is, which allows me to keep separate the company and myself. 🙃
Recently I upgraded pylint and started getting new violations, at which point I discovered that the bar for adding new pylint rules is “some random blog post says not to do X, so let’s make X an error!”
I like that there are so many competing Python linters and think it ultimately reinforces that these style decisions should be local rather than language.
I tend to like flake8 for my projects and this article didn’t convince to switch, and that’s ok.
I’ve tried Pylint a number of times and never found it to be worth the wait. The static checks it can do occasionally find bugs, but it takes so long to do so that I can’t say it is worth the trouble — it is usually easier to write tests for the code than sift through torrents of Pylint output. The tests will be faster and writing them prompts refactoring to make the code better.
If you are in the unfortunate position of working with someone who writes 2,000 line functions the style linting capabilities could be handy. However I’ve found that Pylint’s default limits are generally so small that they cause false positives. IMO a linter should never generate false positives. Setting hard limits on function length tends to force break-up of functions that shouldn’t be broken up.
The best Pylint capability is the ability to “deprecate” modules. This lets you blacklist footgun modules like commands. I’ve also used Pylint to blacklist time.sleep() in Twisted projects.
The logging checker is also really handy, since errors in log format strings may not appear in tests due to lazy interpolation.
(BTW @moshez there is a typo here: 1 <= x && 5 > 5.)
I’ve been running with Pylint auto-enabled within Neovim for quite a while now. It does tend to be a little aggressive, especially when you’re starting a brand new project and functions/variables might be defined but unused, but I have found it to be very valuable and helps make sure that even my 0.1 code is relatively well put together.
My teams use Black with
It’s been working like a champ. I can easily tell who is non-compliant and who is with a single glance. And I very much appreciate the code being “the company’s” not “my style”.
I loved black until their double quote requirement. There’s a lot of discussion and they have a rationale. But hitting that shift key is too much work for me and my projects.
It’s funny that I like the idea of a right, opinionated way but am faced with the reality that finding the right right way is really tough.
I would use them if there was a single quote config setting (or they switched to single quotes, obviously).
I use precommit to run Black and I’ve gotten used to staging my files, adding them to an empty message commit (which aborts it after running black if no changes and aborts the commit if there are changes) before I stage files for the actual commit I want to send out.
It’s a bit annoying from time to time but I marvel at how… uniform and not “my code” it is, which allows me to keep separate the company and myself. 🙃
Recently I upgraded pylint and started getting new violations, at which point I discovered that the bar for adding new pylint rules is “some random blog post says not to do X, so let’s make X an error!”
https://github.com/PyCQA/pylint/issues/2905
I took this as motivation to replace pylint with flake8 and black, and I haven’t looked back.
I like that there are so many competing Python linters and think it ultimately reinforces that these style decisions should be local rather than language.
I tend to like flake8 for my projects and this article didn’t convince to switch, and that’s ok.
I’ve tried Pylint a number of times and never found it to be worth the wait. The static checks it can do occasionally find bugs, but it takes so long to do so that I can’t say it is worth the trouble — it is usually easier to write tests for the code than sift through torrents of Pylint output. The tests will be faster and writing them prompts refactoring to make the code better.
If you are in the unfortunate position of working with someone who writes 2,000 line functions the style linting capabilities could be handy. However I’ve found that Pylint’s default limits are generally so small that they cause false positives. IMO a linter should never generate false positives. Setting hard limits on function length tends to force break-up of functions that shouldn’t be broken up.
The best Pylint capability is the ability to “deprecate” modules. This lets you blacklist footgun modules like
commands. I’ve also used Pylint to blacklisttime.sleep()in Twisted projects.The logging checker is also really handy, since errors in log format strings may not appear in tests due to lazy interpolation.
(BTW @moshez there is a typo here:
1 <= x && 5 > 5.)I’ve been running with Pylint auto-enabled within Neovim for quite a while now. It does tend to be a little aggressive, especially when you’re starting a brand new project and functions/variables might be defined but unused, but I have found it to be very valuable and helps make sure that even my 0.1 code is relatively well put together.