PEP8 and Phoenix code

[Werner]

Hi,

Just the other day I came across autopep8 -
https://pypi.python.org/pypi/autopep8

I just tried it on some of the wx.lib.ogl modules.

wx.lib.ogl.basic.py had:
errors = 304
warnings = 269

after running autopep8:
errors = 18
warnings = 6

The remaining warnings where whitespace (W291) within documentation
strings and the errors where all line length warnings (E501 , with a
line length of 100 instead of the default79).

Would it, at some point in the future, make sense to use this on wx.lib
to get a more consistent coding style?

Werner

[Metallicow]

Post by Werner
Hi,
Just the other day I came across autopep8 -
https://pypi.python.org/pypi/autopep8
I just tried it on some of the wx.lib.ogl modules.
errors = 304
warnings = 269
errors = 18
warnings = 6
The remaining warnings where whitespace (W291) within documentation
strings and the errors where all line length warnings (E501 , with a
line length of 100 instead of the default79).
Would it, at some point in the future, make sense to use this on wx.lib
to get a more consistent coding style?
Werner

Well, sorta. Something like this should be very carefully approached .

I occasionally(every once and a while, but at least once) use the PEP8 and
AutoPEP8 for my projects to clean up obvious stuff as far as readability
and obvious errors are concerned, but note only one feature is used at any
given time.
Then the code MUST be checked manually by a human being(Ex: in a diff
viewer) to make sure that the program didn't chew up the input code and
spit out something unusable or that would irritate others according to
general coding style.
It is a very debated issue for most projects as PEP8 isn't but a basic
style guide. Most style points are agreeable on, but not all(esp by
everyone). Ex: line length, lining up code, etc... that should be avoided.
When in doubt follow the zen. premature optimization is the root of
optimized code sooner rather than later or never at all.

But then again... I think this type of work might rub Robin the wrong way,
when it comes to his free time, as we haven't gotten the trailing space
eradicated yet...
Maybe some day... But HOPEFULLY before Phoenix goes live, we can all agree
on the other cruft that should at least get some attention every once and a
while and get something done about it.
So.. your not the only one that occasionally thinks about these types of
things.
I often see other developers bugged to the brink of "OK, I'll do it. Just
leave me alone for crying out loud." before anything is ever done about
it because they might be the only one with access to change stuff like that
for a project.
Sometimes this takes years. I depends on your priorities and motivation
mostly.

All I ask for is that the code whitespace be trimmed and the readability
consistent throughout(Think like a book) whatever that may entail.

[Metallicow]

Regarding line length: Anything less than 1024 is acceptable generally
overall that won't create an error with todays modern tech. So keeping
lines 999 or less is rule of thumb for cross-compatibility.
Usually this is only done for database stuff(like the pyembedded image
strings) or when "tidy"ing code before a RELz for optimization reasons,
then not meant to be edited again afterward.
But in general 40-80-120-160-200 chars is a norm, depending on the
resolution/max line length. Anything longer would only be easier readable
by a computer, etc...
Shift+ScrollWheel should horizontally scroll also for people with
disabilities or line length peevs, but then again... Not all editors are
created equal.
Not everyone uses a keyboard or mouse to program with and vise versa, so
that should be a concern higher that anything a style guide should ever
influence you to change things stylistically.

[Werner]

Post by Werner
Hi,
Just the other day I came across autopep8 -
https://pypi.python.org/pypi/autopep8
<https://pypi.python.org/pypi/autopep8>
I just tried it on some of the wx.lib.ogl modules.
errors = 304
warnings = 269
errors = 18
warnings = 6
The remaining warnings where whitespace (W291) within documentation
strings and the errors where all line length warnings (E501 , with a
line length of 100 instead of the default79).
Would it, at some point in the future, make sense to use this on wx.lib
to get a more consistent coding style?
Werner
Well, sorta. Something like this should be very carefully approached .
I occasionally(every once and a while, but at least once) use the PEP8
and AutoPEP8 for my projects to clean up obvious stuff as far as
readability and obvious errors are concerned, but note only one
feature is used at any given time.
Then the code MUST be checked manually by a human being(Ex: in a diff
viewer) to make sure that the program didn't chew up the input code
and spit out something unusable or that would irritate others
according to general coding style.

autopep8 seems to try to do things on the 'save side' unless you use the
'aggressive' flag, so this should hopefully not cause big issues.

Post by Werner
It is a very debated issue for most projects as PEP8 isn't but a basic
style guide. Most style points are agreeable on, but not all(esp by
everyone). Ex: line length, lining up code, etc... that should be avoided.
When in doubt follow the zen. premature optimization is the root of
optimized code sooner rather than later or never at all.

The little I saw autopep8 can be configured what one wants it to
optimize or not, so that should technically be easy - until we people
get involved:)

Post by Werner
But then again... I think this type of work might rub Robin the wrong
way, when it comes to his free time, as we haven't gotten the trailing
space eradicated yet...

Definitely don't want to rub Robin the wrong way, and I would be
surprised if this would do it. Anyhow if he says not interested that is
fine with me, if he says yes, then it is obviously him who decides what
should not be used in the autopep8:

https://pypi.python.org/pypi/autopep8/1.0.3#features

Werner

[Metallicow]

Post by Werner
autopep8 seems to try to do things on the 'save side' unless you use the
'aggressive' flag, so this should hopefully not cause big issues.

I don't recall what version I was using but it was probably pre 1.0 or so.
I don't recall if the aggressive flags thing was implemented at that point.
I recall if I didn't specify *exactly* what to do it would just wreak it
all regardless, which made a mess of things in my opinion as it doesn't(or
maybe didn't I should say) make a copy of the files processed before
modding them. It was at that point I decided to just roll my own better
implementation with the PEP8 source hooked into SourceCoder as a python
lexer special option/helper with annotations and a bunch of nicer line by
line type diff viewing graphically like winmerge sorta, but without the
whole auto opps factor.
Plus it is easily configurable as to what to complain about with some
checkbox settings. otherwise you get obviously time wasting lines such as
the one in the attached screenie. ?!? Whaddaya mean space after # ... see
what I mean. certain things should be ignored of course per settings like a
code commented style with two ##, etc...

Post by Werner
It is a very debated issue for most projects as PEP8 isn't but a basic
style guide. Most style points are agreeable on, but not all(esp by
everyone). Ex: line length, lining up code, etc... that should be avoided.
When in doubt follow the zen. premature optimization is the root of
optimized code sooner rather than later or never at all.
The little I saw autopep8 can be configured what one wants it to optimize
or not, so that should technically be easy - until we people get involved:)

I see the version is 1.0.3 now. I'll have another look at what has changed
since older versions. Hopefully it has fixed some of the over sites earlier
versions had and make things easier to get done without extra hassle.