It would be useful to clean these up eventually. I and others have been updating modules to be more PEP8 compliant as we go through and implement improvements. Fine to continue in that fashion or to selectively do PEP8 updates. It would be good to avoid changing a lot of files at the same time, just because it makes it harder to review and comment on things.

There was an attempt to do this in PR ##283 but it was a bit too aggressive and ultimately withdrawn.

One solution to fix this now, and automatically going forward is to leverage an automatic code formatting tool like black.

mongodb's engineering team wrote a series of posts about how they've had a lot of success with automatic code formatting tools. (They're using C++ & Clang-format, but the principles are the same).

But even with smaller projects, most developers discover the problems of working without an agreed upon format the very first time they work on a team. This irritation can lead to religious arguments over the merits of various formatting choices; but mature engineers know that a standard is more important than which standard. - Succeeding With ClangFormat, Part 1: Pitfalls And Planning

I ran black, reorder-python-imports, and cleaned up trailing white spaces on a branch in my fork.

This is the commit diff:

AutomotiveDevOps@312b894

For an established project it is a big bandaid to pull off at once, but after that if you lean on the tooling then it should be smooth thereafter.

black is very successful in nonnumeric codea but unfortunately destroys any array alignment or longer function signatures and long string messages. So makes the code unreadable at some point which we also tried a few times on SciPy code.