[GitHub] bjustin-ibm commented on issue #149: Updating all Python files to have ASF licenses and pass PEP8 tests

[gi...@git.apache.org]

bjustin-ibm commented on issue #149: Updating all Python files to have ASF licenses and pass PEP8 tests
URL: https://github.com/apache/incubator-openwhisk-package-kafka/pull/149#issuecomment-312298927
 
 
   > These are all changes to adhere to PEP8 (<80 char lines and other things) that may appear "cosmetic" but to the Python community makes a significant different in terms of "correctness" to Python agreed-upon standards.
   
   I respectfully disagree about the line length. A quick survey of Stackoverflow shows that the 79 character limit imposed by PEP8 is extremely contentious and hotly debated. 
   
   - https://stackoverflow.com/a/17319775
   - https://stackoverflow.com/a/2793525
   
   If you read PEP8 itself, they not only recognize this contention, but also explain that it is done only for readability on legacy displays which are only capable of displaying content 80 characters wide. It also allows for development teams to agree to enforce a longer line length: https://www.python.org/dev/peps/pep-0008/#maximum-line-length
   
   As a development team, I think we can agree that we are not developing this code on legacy displays that are incapable of displaying more than 80 characters and _also_ incapable of soft-wrapping long lines. I contend that the string breaking changes included in this PR actually reduce the readability of the code, rather than enhance it - e.g. [this proposed change](https://github.com/apache/incubator-openwhisk-package-kafka/pull/149/files/d91656bd7a3e5f68384489e998132efc99fe7966#diff-c7f0a1458defdca4247d971225ee27baR131).
   
   I welcome a standard code formatting so long as it can be automated, and does not detract from the actual readability of the code by imposing an arcane limitation. 
   
   I have some concrete suggestions for how to proceed:
   - Please include a `pep8.rc` file that matches what scanCode expects. This will give us awareness of what needs to change without waiting for Travis, as well as the ability to configure our development tools to automatically fix the style issues.
   - In that config file, let's set the line limit to either 120 or 160 characters. This will bring some amount of rigor and conformity to our formatting, without necessarily decreasing the readability.
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services