This commit brings pyArango significantly closer to PEP 8 complience.

[NeilduToit13]

Rationale: The main reason for building a Python driver for an third-party API is, or should be, to allow Pythonic access to the service that is clear and understandable to a typical Python developer, and to simplify the process from having to use requests with custom JSON.

PEP 8 should be applied unless:

• There are project specific guidelines which take precedence. This is an open-source project and hence should not be creating its own guidelines that are vastly different from the recommended guidlines.
• For backwards compatability. This is a new project, so there is no such requirement.
• Applying PEP 8 renders the code unreadable. This does not apply here, as the reason that I wrote this commit is precisely because I could not read the code without PEP 8.
• The code predates the guidline. This does not apply.
• Compatability with older versions of Python. I have left some code intact for this reason (for example, explicitly extending the Object class, which is redundant in Python3, has been left for Python 2 compatability). However, this library is likely to primarily be used by Python3 developers, and a future pull-request will introduce Python3 style improvements and optimisations.

Many of the fixes in this commit also resolve internal inconsistencies (for example, highly inconsistent doc-string usage, and differing names for variables serving the equivalent function in different locations), which is a problem regardless of the coding style adopted.

Key Changes:

• Splitting longer lines over multiple lines (PEP recomments 79 character line length).
• Blank lines: From PEP, two lines between top-level definitions, one between methods. This had not been followed.
• Imports: some module-level imports were not at the top of files as required by PEP. They have been moved.
• Docstrings: Changed to triple quotes everywhere (PEP 257) : Placed the """ on separate lines. PEP 8 regards leaving the trailing """ on a separate line as "most important". This had not been followed.
• Whitespaces: Amazingly, almost every one of the "Pet Peeves" for whitespaces listed in PEP 8 were used. Theses are particularly annoying and unnecessary. They have been removed.
• Naming conventions: I have not changed too many names because I am not yet familiar enough with the code to always have good names. However, all variable and function names were CamelCase, which is incorrect. They have been corrected. : Single-letter variable names have been replaced whereever possible. : In particlar, the letter 'o' was used as a variable name, which is highly inadvisable due to confusion with 0. O is explicitly prohibited by PEP, but the same reasoning applies to o. : I have replaced many abbreviations. Especially cases where multiple DIFFERENT abbreviations were used for the same variable name, leading to confusion.

Changes Still Required:

• Names that clash with reserved words have been incorrectly adapted (PEP 8 - Function and Method Arguments)
• Classes inhereting from Object don't need to do so explicitly, unless there is a Python 2 reason for doing this.
• Function annotations may be helpful in certain cases.
• The actual content of the comments is currently entirely unhelpful and docstrings in particular need to all be rewritten.

[tariqdaouda]

Hi @NeilduToit13,

Thanks for this. However is not a new project it has been developed for years now and I cannot integrate this pull-request it because it breaks backward compatibility.

The API has been designed to resemble as much as possible the javascript API, which at the time was pretty much the only available API for ArangoDB, and mainly the http API, hence the use of camelCase for argument name. This does not make it PEP 8 compliant, but it makes it easier to switch from one language to another, but also to use the documentation ArangoDB's http api.

pyArango started as a python2 project, and I myself still need some backward compatibility for some python2 applications. More compliance with python3 guidelines will come, but it's not a high priority.

I little PEP 8, but I am not a PEP 8 fanatic, I don't think it makes things necessarily more readable and I especially don't care about "pet peeves" whitespaces. They are based upon the English language aesthetics and I like the French " :" and " = ". I remove trailing whitespaces when I see them, but otherwise they do not bother me. My editor hides them and they are only a hnderence if you don't know how to navigate code efficiently.

However, PEP 8 does makes part of the code more readable. I will gladly merge anything that makes pyArango compliant PEP 8 compliant, as long as it does not break backward compatibility, and the one-to-one correspondence between argument names and the arguments in the http api documentation.

Cheers,

[dothebart]

https://github.com/ArangoDB-Community/pyArango/pull/153 will give us the easily parts of this that touch many places. I may add more PRs achieving parts of this pr.