PEP 8 style enforcing program

[montyphyton]

Some recent posts about Python programming style got me thinking.
Since we have the PEP 8 which gives some guidelines about the style to
be used, do we have any program that can check for violations of these
guidelines within the source code? I understand that there are a lot
of code beautifiers out there, but i haven't seen one specially
tailored for Python... Is there even a desire in Python community for
a program like this (by Python community I mean the people in this
group:) ) ? I think it would be a nice little project for practice and
I'd like to do it, but if there is already something like this then I
can probably spend my time on something more productive. So, I'd like
to hear your opinion on this...
There is one thing that I don't understand about PEP 8 - why is using
spaces considered more desirable than using tabs for indentation?

[Alexander Eisenhuth]

mo*********@gmail.com schrieb:

Some recent posts about Python programming style got me thinking.
Since we have the PEP 8 which gives some guidelines about the style to
be used, do we have any program that can check for violations of these
guidelines within the source code? I understand that there are a lot
of code beautifiers out there, but i haven't seen one specially
tailored for Python... Is there even a desire in Python community for
a program like this (by Python community I mean the people in this
group:) ) ? I think it would be a nice little project for practice and
I'd like to do it, but if there is already something like this then I
can probably spend my time on something more productive. So, I'd like
to hear your opinion on this...
There is one thing that I don't understand about PEP 8 - why is using
spaces considered more desirable than using tabs for indentation?

Pylint is one of them (http://www.logilab.org/857)

With spaces you get always the same len of the line, where tabs can use 2,4,8
spaces, dependingt on the settings of the IDE

Alexander

[Chuck Rhode]

montyphyton wrote this on Thu, 31 May 2007 05:16:30 -0700. My reply
is below.

I understand that there are a lot of code beautifiers out there, but
i haven't seen one specially tailored for Python.

Consider PythonTidy:

o http://lacusveris.com/PythonTidy/PythonTidy.python

--
... Chuck Rhode, Sheboygan, WI, USA
... Weather: http://LacusVeris.com/WX
... 75° — Wind SSE 9 mph — Sky haze.

[Bjoern Schliessmann]

Alexander Eisenhuth wrote:

Pylint is one of them (http://www.logilab.org/857)

BTW: Why does pylint want all names with underscores? I tested it
and it complains about malformed names in e.g. the following cases
that are conformant to PEP 8:

- single letter as parameter
- firstLowerCamelCase names for instances and instance methods in
class declarations ("should match [a-z_][a-z0-9_]{2,30}$")
- all lowercase method names in class declarations

Those policies are barely usable, IMHO, and neither practical.

LOL, and it rates my code -1.9/10. The minus is no typo.

Regards,
Björn

--
BOFH excuse #291:

Due to the CDA, we no longer have a root account.

[Eduardo \EdCrypt\ O. Padoan]

On 5/31/07, Bjoern Schliessmann
<us**************************@spamgourmet.comwrote :

Alexander Eisenhuth wrote:

Pylint is one of them (http://www.logilab.org/857)

BTW: Why does pylint want all names with underscores? I tested it
and it complains about malformed names in e.g. the following cases
that are conformant to PEP 8:

- single letter as parameter

This seems to be an Logilab internal restriction.

- firstLowerCamelCase names for instances and instance methods in
class declarations ("should match [a-z_][a-z0-9_]{2,30}$")
- all lowercase method names in class declarations

No. Quoting PEP 8:
Functions:
"""
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards compatibility.
"""
Methods and instances:
"""
Use the function naming rules: lowercase with words separated by
underscores as necessary to improve readability.
"""

Those policies are barely usable, IMHO, and neither practical.

I Desagree.

--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt

[Bjoern Schliessmann]

Eduardo "EdCrypt" O. Padoan wrote:

No. Quoting PEP 8:
Functions:
"""
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards
compatibility.
"""
Methods and instances:
"""
Use the function naming rules: lowercase with words separated by
underscores as necessary to improve readability.
"""

Has this been updated recently? I could've sworn I had read that
stuff like has_key was "old".

Regards,
Björn

--
BOFH excuse #432:

Borg nanites have infested the server

[Steven Bethard]

Bjoern Schliessmann wrote:

Eduardo "EdCrypt" O. Padoan wrote:

>No. Quoting PEP 8:
Functions:
"""
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards
compatibility.
"""
Methods and instances:
"""
Use the function naming rules: lowercase with words separated by
underscores as necessary to improve readability.
"""

Has this been updated recently? I could've sworn I had read that
stuff like has_key was "old".

You can check the revision history here:

http://svn.python.org/view/peps/trun...55405&view=log

Looks to me like camelCase became unacceptable in Revision 1781, back in
March 2004.

STeVe

[Marc 'BlackJack' Rintsch]

In <5c*************@mid.individual.net>, Bjoern Schliessmann wrote:

[ripped out of context :-)]
Has this been updated recently? I could've sworn I had read that
stuff like has_key was "old".

Yes, `has_key()` is "old", it's spelled ``in`` these days. :-)

if mapping.has_key(ham): pass

# ->

if ham in mapping: pass

Ciao,
Marc 'BlackJack' Rintsch