Python conventions

[MartinRinehart]

I assembled a good conventions set for Java. View it at
http://www.martinrinehart.com/articles/code-conventions.html (is that
better, Steve?)

It followed a logical organization; it was built from four other
extensive (if not well-organized) convention sets and it scrupulously
avoided injecting my own biases. Where there were disagreements, they
were noted and the opposing viewpoints explained.

I'm appointing myself project secretary of a similar effort for
Python, until we can find someone better qualified (Python experience
pre-dating my late '07 start would be better qualified). The
secretary's job is to ask questions and correctly record answers.
First question:

global (e.g., what language for comments)
package
module
class
methods
data
function
statement
expression
variable

Is this a good outer-level organization?

For each topic, cover:

documentation
naming convention(s)
format

Second question: are the above the items we cover for each topic?
Others?

 

[Daniel Fetchinson]

I assembled a good conventions set for Java. View it at

http://www.martinrinehart.com/articles/code-conventions.html (is that
better, Steve?)

It followed a logical organization; it was built from four other
extensive (if not well-organized) convention sets and it scrupulously
avoided injecting my own biases. Where there were disagreements, they
were noted and the opposing viewpoints explained.

I'm appointing myself project secretary of a similar effort for
Python, until we can find someone better qualified (Python experience
pre-dating my late '07 start would be better qualified). The
secretary's job is to ask questions and correctly record answers.
First question:

global (e.g., what language for comments)
package
module
class
methods
data
function
statement
expression
variable

Is this a good outer-level organization?

For each topic, cover:

documentation
naming convention(s)
format

Second question: are the above the items we cover for each topic?
Others?

I'm sorry to disappoint you but this project has already been completed:

http://www.python.org/dev/peps/pep-0008/

Cheers,
Daniel

 

[MartinRinehart]

I'm sorry to disappoint you but this project has already been completed:

http://www.python.org/dev/peps/pep-0008/

Daniel, PEP 8 is anything but complete. How much of the following
simple question can you answer from there:

Given that you can name things with UpperAndLower, lowerAndUpper,
lower_and_underscore, etc., what is the convention for naming
packages, modules, classes, ...

PEP 8 very much reminds me of Sun's Java conventions - a start, but
only a start. Also, in part, controversial. (How wide do you think
Python code should be?) Finally, lacking in basic organization. (This
seems to be a disease that infects almost all standards.) We can do
better. As a guess, GvR would be happy to have someone fill out PEP 8.

 

[Jerry Hill]

Daniel, PEP 8 is anything but complete. How much of the following
simple question can you answer from there:

Given that you can name things with UpperAndLower, lowerAndUpper,
lower_and_underscore, etc., what is the convention for naming
packages, modules, classes, ...

Each of those is directly addressed in PEP 8. Perhaps you should have
picked a different question?

 

[Daniel Fetchinson]

I'm sorry to disappoint you but this project has already been completed:

Daniel, PEP 8 is anything but complete. How much of the following
simple question can you answer from there:

Given that you can name things with UpperAndLower, lowerAndUpper,
lower_and_underscore, etc., what is the convention for naming
packages, modules, classes, ...

These are actually spelled out in quite some detail.

PEP 8 very much reminds me of Sun's Java conventions - a start, but
only a start. Also, in part, controversial.

Which is natural because it's not a standard, only a recommendation.

(How wide do you think Python code should be?)

I don't think it should be part of any recommendation.

Finally, lacking in basic organization.

What would it gain by having 'basic organization'?

(This seems to be a disease that infects almost all standards.)

PEP-8 is not a standard, it's a recommendation that may or may not be
followed without any consequences.

We can do better.

What would we -- or anyone -- gain by doing better?

As a guess, GvR would be happy to have someone fill out PEP 8.

Did you ask him?

I personally think that since coding convention is what it is -- a
convention -- it should not be codified by any recommendation or
standard or some such any further than PEP-8. You might think of
course otherwise and might put together a stricter and more
encompassing document if you think that's useful, just don't expect
anyone to follow it.

Cheers,
Daniel

 

[Gabriel Genellina]

Daniel, PEP 8 is anything but complete. How much of the following
simple question can you answer from there:

Given that you can name things with UpperAndLower, lowerAndUpper,
lower_and_underscore, etc., what is the convention for naming
packages, modules, classes, ...

PEP 8 very much reminds me of Sun's Java conventions - a start, but
only a start. Also, in part, controversial. (How wide do you think
Python code should be?) Finally, lacking in basic organization. (This
seems to be a disease that infects almost all standards.) We can do
better. As a guess, GvR would be happy to have someone fill out PEP 8.

This feels like a dejà-vu... Your thread from last January:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/96fac33ed9d601b7/

If you like doing these kind of things, go ahead and summarize them. You
have more than 30 style guides to start with. Enjoy.

 

[John Nagle]

I'm sorry to disappoint you but this project has already been completed:

http://www.python.org/dev/peps/pep-0008/

Good point.

It's probably time for CPython to enforce the rule that you can
indent with either tabs or spaces, but cannot mix them. Which
to use is ideological; mixing them is a bug.

John Nagle