[gdal-dev] PEP8 compliance for Python code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] PEP8 compliance for Python code

Ben Elliston
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: PEP8 compliance for Python code

Even Rouault-2
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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: PEP8 compliance for Python code

Ben Elliston
On 10/04/18 19:05, Even Rouault wrote:

> Apparently autopep8 can fix most of issues, except line too longs ?

I think that's right. I would not plan to touch long lines. The worst of
them can be fixed over time when other edits are taking place.

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

Right. We'll just skip those files.

Cheers, Ben
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev