Robert Rees
POP Developers
Published in
2 min readNov 15, 2018

--

I have been experimenting with some opinionated tools to simplify our Python development. The two tools I’ve been trying are Prospector and Black.

Prospector

Prospector is an opinionated layer over a suite of tools such as Pylint and Pyflakes which reduces the noise that those tools generate. Instead if gives you a collected subset of issues that I have generally found to be the useful 80% of the underlying tools rather than the noise.

For example, on my first run of it Prospector correctly pointed out the complexity issues with a piece of code which was syntactically and conventionally right and was being accepted by our current linters.

The section was indeed a deeply nested gnarly piece of code that it was possible to make far more maintainable via some short circuit logic.

Useful on its first run, that’s the kind of tool I like!

At its default setting Prospector is lenient about things like string delimiters, line lengths and doc strings which means you can afford to play around a bit with code formatting and structure.

This means you can bring in a tool like Black and not have to mess around with a bunch of linting rules and exceptions. Black is opinionated about using double-quotes and its own line length that optimises for file length so using it with a tool like flake8 would be a nightmare.

Black

Black is a fairly straight-forward tool which basically just formats your code. You point it at a file or a directory and it goes away and does its thing rewriting the code according to its rules.

So far I haven’t been brave enough to apply it to an entire codebase but I have been using it to tidy modules after I’ve finished coding.

I’ve only had a short time to live with the results and so far I haven’t come across anything confusing or aesthetically awful. My main gripe is that putting dictionaries on a single line can make them harder to read and needlessly generates diffs should the content of the dictionary change.

Black transforms code using the AST of the code file and has not yet hit a 1.0 release so having a test suite and a pragmatic code linter like Prospector has helped me feel that the code transformations have been correctly limited to style changes.

The benefit of opinionated formatters

Whatever feelings I have about some of Black’s style choices I’m not going to miss line-length discussions or linting nags about code that go over the line limit by one or two characters.

We already use Prettier for our Javascript and I’m not a massive fan of the way that tool formats code but on the other hand we’ve had zero discussions on pull requests about code style and formatting since we introduced it and that’s a massive productivity gain.

We’re waiting for a stable release of Black before we apply it universally to our main codebase but that’s really the only thing holding back our adoption. I’d expecting to increasingly adopted as a standard Python development tool.

--

--