[Tutor] Re: Re: working code for adding line numbers -- request for
project5 at redrival.net
Mon Apr 19 09:15:42 EDT 2004
Brian van den Broek wrote on Sunday 18 April 2004 20:00:
>> If you code this kind of stuff properly, it will generally be
>> cross-platform without you even thinking about it :).
> I was mostly thinking about the lines:
> else: dirname = os.path.dirname(tfilename).capitalize()
Ah, you're right, changing caps on non-Windows systems isn't a great idea. I
would avoid manipulation file names for frivolous reasons - it breaks
cross-platformness and doesn't really gain you anything.
> Since the user could type "c:\myfile.txt" without that .capitalize()
> method the dirname came out as "c:". Forcing it to be "C:" seemed the part
Is C really standard notation on Windows? I don't tend to type caps in
command lines and such to be honest. I've noticed in other people's code
that lowercase tends to be used for drives even if Explorer shows uppercase
names. Ah well, I don't think anyone would be confused by seeing "c:"
instead of "C:", since humans aren't case-sensitive.
> specific to DOS/Win systems. (I don't know the Lin/UNix drive conventions,
> but Alan pointed out in a previous post that something I was doing was DOS
> drive convention centered.) But that is a small thing.
*nix doesn't have drives :), everything is a directory. The CD-ROM is
something along the lines of /mnt/cdrom (with / being the root of the file
system). A directory can be on any drive on *nix, the user doesn't know nor
care where exactly it's located when using the OS. In that respect all
directories are like "My Documents" in Windows, which appears to be a
top-level directory but is actually hidden somewhere in "c:\Documents and
> install-fests and have yet to come away with a working Linux install on my
> laptop :-( , but I hope to be free soon :-), and definitely didn't want my
> early steps in programming to be Win-centric.
Ah, you must have come across some of those problems with Win-only hardware.
Used to have a modem and soundcard like that. I'm a Linux newbie, but what
I've noticed is that distro's get better at hardware detection all the
time. Everything works for me now (didn't 1 year ago), except that I can't
get my printer to work (attached to a router/printer server which the
manufacturar - SMC - so far refuses to support under Linux, even though the
machine shouldn't have anything platform-specific about it).
> I'd thought it the multiple statements on a line OK for simple statements
> and a good thing in that more code could be seen on the screen at once.
I avoid multiple statements on the same line like the plague. Not just in
Python, but in any language. I only use them e.g. when using the timeit
module, or when I post a code sample and need to do some initializations
first which are not relevant to the sample itself, but never in real code.
> I absolutely see the point with respect to the print statement. But I
> wonder then where to put the comments on the variable names. I put them
I try to put short comments at then end of the line, long comments as
docstrings to a method. But I'll get back to this topic below.
> there as that is where the "sfilename" is defined and I thought that a
> longer, more self-documenting name such as "source_filename" would be
> getting too long. (I don't recall if it was this variable or another, but
I agree there :). I don't quite agree with your choice of abbreviation (the
"source" part is IMO more important than the "filename" part, yet the
"source" is abbreviated to one letter, while the other part remains intact.
I'd rather use something like "sourcefn"/"source"/"sourcefile" than
"sfilename", but it's not that bad - it would be bad if you'd named it "x"
or something :)).
This point is related to comments, since good variable names prevent the
need for some comments. The line "source = getfilename()" makes it
immediately clear that source is a file name of a source file, there's no
need to comment the obvious - unless of course the getfilename method
doesn't do what its name suggests :).
One could argue that variable names which need comment to be explained
aren't good names, but I'm not sure that's true in all cases :).
>> dirname = os.getcwd() # file in current directory
> But in the last line quoted above, I'm not sure what you mean. It seemed
> to me that os.getcwd() did return a capitalized drive letter and the only
Oh, well, if that's the case, you're right. I had no idea what kind of caps
> The line numbers at the front is how I did it at first. But unless I miss
> your meaning, it seemed a bad idea. Consider:
> assuming that the def line was the first line of the file (not likely, but
> its an e.g. :-) ) and every 5 lines were numbered, this would get rendered
> something like:
> def some_function:
> first line here
> if some condition:
> third line here
> # 5 fourth line here
> fifth line here
> That would, I think, make it harder for me to process what belonged to
> what block.
You're right, it would. But I could give you a counter-argument:
some very long line doing interesting things # comment
some other long line doing other stuff # comment # 3
and another line with statements # comment
That #3 will not jump at you like it would at the start of the line, and
even less if you view the file in a syntax coloring editor. So instead,
here's an elegant solution with the best of both worlds :): indent ALL
lines by say 5 spaces, but only add numbers in front of those where numbers
are required. Adjust the numbers to make sure that the number plus
trailing/leading spaces equals 5 characters. This would make your code look
2 first line here
if some condition:
4 third line here
fourth line here
6 fifth line here
Format strings are useful for this purpose.
Real contact info (decode with rot13):
cebwrpg5 at jnanqbb.ay. Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V ernq
gur yvfg, fb gurer'f ab arrq gb PP.
More information about the Tutor