Changes

First rule is to use the same style as the existing code around your new method, class or module. Sugar code is quite consistent as of now (August 6th 2009) so you shouldn't need to change styles often except when modifying very old code.

First rule is to use the same style as the existing code around your new method, class or module. Sugar code is quite consistent as of now (August 6th 2009) so you shouldn't need to change styles often except when modifying very old code.

Follow [http://www.python.org/dev/peps/pep-0008/ PEP 08], though it is quite broad so it's not enough to guarantee a minimum of consistency.

Follow [http://www.python.org/dev/peps/pep-0008/ PEP 08], but as it is quite broad, it's not enough in itself to guarantee a minimum of consistency. Some more comments below.

Use inline comments sparingly. If you feel your code needs an inline comment, consider instead splitting the method in two, with a reasonable name and API docs. API comments should say '''what''' the code does, not '''how''' it does it. How your code works should be clear from the code structure, refactor until the code structure is a clear reflection of its purpose.

Use inline comments sparingly. If you feel your code needs an inline comment, consider instead splitting the method in two, with a reasonable name and API comment. API comments should say '''what''' the code does, not '''how''' it does it. How your code works should be clear from the code structure, refactor until the code structure is a clear reflection of its purpose.