PEP8 and minor fixes

[kamichal]

https://www.python.org/dev/peps/pep-0008/

One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".

The code becomes formatted in such way that autoformatters like autopep8.py does not affect it (finds the code style clean).

Actions:

• applied PEP8
• arranged imports, removed wildcard and unused imports
• fixed unused variables and names colliding with builit-ins (e.g. id, buffer, bytes, file, str, etc..)
• removed tabbed indentation

Next step is to add tox running pytest on supported python interpreters and flake8 linter.

[alistair23]

Hey Michal,

I am happy to review this, but first do you mind rebasing it on the current master?

[kamichal]

Sure, that's of course not a problem. Or rather: it's my duty to make it "mergable" with master without any conflicts. The only one obstacle is my free time. I think I'll manage it in several days.

[alistair23]

No worries. If possible it would be nice to have it split up into smaller pull requests. It just makes the review easier. So don't feel like you need to do it all in one go.

[kamichal]

OK I brought it into 'mergable to master' state. This PR is ready to be review, although it's mainly only white-space change. Now it's clean as a "well written prose" :)
BTW I'm sorry it took so long.

[alistair23]

Is it posible to split the PEP patch into smaller ones? It's really hard to review as a single patch. If you can't do this I can do it for you. It should be fairly straight forward to split it up.

Also can you consolidate the other changes into a single patch? Why do you need to change the Travis file?

[kamichal]

Is it posible to split the PEP patch into smaller ones? It's really hard to review as a single patch.

Hey, I know it's large, but it takes just 30 minutes to review it all. All of these are whitespace changes so the review is just scrolling down. These all are unrelated changes, so you can do a few-days break in reviewing and then come back forgiving everything you read before.

Also can you consolidate the other changes into a single patch?

I removed all the commits from august 2018 and started from current master's branch HEAD.

Why do you need to change the Travis file?

I added tox configuration, it's a test automation tool that cares for installing all dependencies in separate sterile virtual environments for each interpreter defined: python 2.7, 3.4, 3.5, 3.6, 3.7 and also pypy. It runs pytest and flake8 (linter). It checks if the tested package is well configured for installation. To use it you just need to call tox in main directory. It cares for everything, so that you don't need to commit/push/wait for Travis results - you can run all of it locally on your machine.
I reconfigured travis to call call tox under-hood. It tests more than plain pytest.

[alistair23]

I have tidied up the travis changes as the three different commits changing the file is very hard to understand. I also split out the white space changes to make it easier to read and review. How does this branch look? https://github.com/alistair23/python-OBD/tree/alistair/pep-fixes

[kamichal]

You forgot to remove stages definition from the yml. Seems I have a trouble understanding your intentions. I don't know how you do a review, but I ussually analyze diff between two branches, not for separate commits, e.g. with creating github's Pull Request, as this one: https://github.com/brendan-w/python-OBD/pull/115/files. This view combines each commit into one big diff between two branches. Github makes it for you.

[alistair23]

The problem with just looking at the diff is then when the commits are merged you end up with a broken history. The CI breaks in the middle of your series which will make bisecting difficult. It also makes it difficult to revert if need be.

[alistair23]

It also ends up being confusing with multiple commits conflicting with each other. For example your series would check in the stages section in the travis.yml file, but apparently you didn't mean to.

[alistair23]

After some more research I have created hopefully the final PR for the PEP8 fixes. It is all based on your work.

Can you please review the PR #141 and let me know if that works for you? You should be able to use GitHub to review the new PR. I have marked you as an author of the commits.

I am sorry this has been such a hassle. Part of it is my lack of knowledge about PEP8. In future this process will be easier if you have clearly defined commits that can be cleanly applied and reviewed.

[kamichal]

I reviewed the PR #141. It's ok. I added a few comments clarifying why is it done this way.