Thanks for leading this.
Apparently autopep8 can fix most of issues, except line too longs ?
Do you plan to fix even that ? That could be quite painful now, and in the 
future, as in the testing code, you compare things like WKT strings that can 
be long, and that would be a burden to make sure we split them to 80 columns. 

I guess your plans do not cover the SWIG generated .py files, right ?


> The Python code in the GDAL tree covers a few things including the
> testsuite and a Python module for GDAL itself.  There is quite a lot of
> this code and the coding conventions are a bit all over the place. There
> are several deprecated idioms still being used.  I think we should
> settle on the Python PEP8 coding style guidelines as a way of
> standardising the appearance of the code across the tree.
> I have so far made a small number of changes detected with 'flake8', but
> some of the changes (such as removing extraneous spaces around
> parentheses) are quite invasive and should be done more carefully.
> I propose to use the 'autopep8' tool to automatically fix all of the
> trivial problems to do with whitespace. This is much faster than manual
> editing and reduces the risk of errors. I plan to inspect the diffs and
> run 'git diff -w' to double check that there are no non-whitespace
> changes. The changes would be made one warning category at a time, on
> cascading (serial) git branches so that there will be minimal merge
> conflicts. Having a number of parallel branches is just asking for many
> merge conflicts.
> At the end of all this, we can enable flake8 support in Travis CI to
> maintain compliance with the coding standard.
> Thoughts?
> Cheers, Ben
> _______________________________________________
> gdal-dev mailing list

Spatialys - Geospatial professional services
gdal-dev mailing list

Reply via email to