Hi,
I for one would prefer to stik to PEP 8 as much as possible. The
reason being that most of the Python code out there follows PEP 8
already. Since we will be using third-party code, it makes sense to
try and conform to whatever standard is already there.
In this respect, I think Russell's proposal is pretty good and very
reasonable. Not to mention that it plays well with editors out there
(without heavy user configuration).
On a side note, it is true that we all have big wide screen, however
it is nice to do quick edits in vi using two terminal windows side by
side on a 12" laptop and not have all those nasty line wraps all over
the screen. That is where, in my opinion, the dreaded 79 col limit
still makes sense.
Cheers,
Francesco
On Nov 28, 2006, at 1:28 PM, Robert Lupton wrote:
Comments on Russell's python coding document:
1/ I think that the 79 character rule is a relict of vt100s and it's
time to move on. We used 109 in Pan-STARRS and I certainly find
it hard to go back to 79. If we do, then the indent of 4 spaces
is probably too many; 3 is perfectly readable (and 2's OK).
I think that we certainly need to increase the ratio
LineLength/IndentWidth
2/ The whitespace looks fine, Except that I'd use white space to
indicate operator priority: Specifically, no white space around
operators that bind at least as hard as *. This implies
hypot2 = x*x + y*y
Russell's already doing this when he forbids space before the ( of a
function call --- it's easier to read
sqrt(2) than
sqrt (2)
3/ I think that we need to specify an indent column for inline
comments. I used 40 for Pan-STARRS.
4/ Russell writes:
> Module names are mapped to file names, so always assume a
> case-sensitive file system and use the case that matches the file
> name in import statements.
This says, "Use the same case as the filesystem". In addition,
we should assume a case _insensitive_ filesystem when naming
files! Some filesystems [e.g. the one that I'm typing this on]
don't distinguish Name and name.
5/ We need to think about what exceptions we'll be raising. I don't
think that we want every module raising its own derived exceptions
(am I wrong?).
6/ Russell writes:
> New in Python 2.5
Are we using 2.5, or sticking with 2.4 (2.3?). I do NOT want to be
always chasing the bleeding edge.
7/ Russell writes:
> Use ''.startswith() and ''.endswith() instead of string slicing
I would personally prefer to always use re.search()
re.search(r"^prefix", str)
as it's
a. Standard
b. Extensible
R
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
