At 3:28 PM -0500 2006-11-28, 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
I'm fine with this if others agree.
Personally, I strongly prefer to use tabs (of width 4 spaces) instead
of spaces. I also have never worried about line lengths in my own
code, but am happy to do so.
but I can't imagine tabs "flying" with others, which is why I
followed PEP 8 and a preliminary LSST C++ standard instead of my own
personal inclinations.
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
I'm neutral.
3/ I think that we need to specify an indent column for inline
comments. I used 40 for Pan-STARRS.
I strongly disagree, for these reasons:
- This is not configurable in all editors (we don't all use emacs).
- If it follows a short line, e.g.:
foo += 1 # skip the margin
I find it very difficult be sure which line has the comment.
I strongly prefer a few spaces followed by the comment
(in the rare cases where I use inline comments).
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.
I thought my rule was sufficient.
In my experience on unix, MacOS X and Windows: if a python source
file name has a particular case, it can always be imported using that
same case.
It is true that, if the file system is not case sensitive then you
may be able to import a module using some other case as well. But
that is terrible practice because the code will fail on a
case-sensitive file system.
Thus my rule. What other situations need to be covered?
As an aside, I one TUI user had an exotic problem with image files
once. They were on a Windows box and saving images to a unix
partition (which were then read back for display). The images could
not be read back because the case got changed as the files were
saved. Perhaps there's a hint in this, but it is not relevant to
source code names vs import statements.
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?).
Maybe a rule is a good idea.
Personally I almost always raise existing standard exceptions. They
are quite extensive and cover most cases nicely. Occasionally I find
it helpful to define my own exceptions.
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.
2.5 is not the bleeding edge. It is quite stable and well tested. It
has some useful new features including relative import.
Python has had excellent backwards compatibility for many years, so
this has little or no effect on using older packages.
Since the LSST is a long term project, this may come up again in the
future. I suggest we not try to set any rules about it for now. For
one thing Python "3000" *may* be next after 2.5 and that is
explicitly *not* backwards compatible.
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
I disagree. In my opinion regular expressions are a big hammer that
should be reserved for cases where they are appropriate. In this case
they will be slower and the results will be harder to read.
-- Russell
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
