[gdal-dev] PEP8 compliance for Python code

[Even Rouault]

Ben,

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 ?

Even

> 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com