[Tutor] working code for adding line numbers -- request for criticism

[Brian van den Broek]

Lloyd Kvam said unto the world upon 17/04/2004 17:18:

 > On Sat, 2004-04-17 at 15:56, Brian van den Broek wrote:
 >
 >>Hi all,
 >>
 >>having learned the lessons of posting under-thought-out questions and not
 >>wishing to further test the goodwill of those on the list, I have code to 
post
 >>this time! (Thanks again for past tolerance.)
 >>
 >>I've found that traceback errors identified by line numbers can be tricky to
 >>track down without line number indications in the code or the editor. (IDLE
 >>doesn't seem to provide for line numbers, and it's no fun counting line on
 >>screen in a long file.)
 >
 >
 > Use Alt-G to jump to a line.  (Works for me in Linux & WinNT)

Hi Lloyd,

Well, that *is* handy. Not sure how I missed that in IDLE's Edit menu, but
there you go. Thanks!


 >>So, I wrote a script to take a file and output a file
 >>with line number comments added. (BTW, is there a module that will do 
this? If
 >>so, no harm, as the exercise was useful, but I'd probably be better off 
with a
 >>module than my script.)
 >>
 >>I've worked through a way to do it. But I'd very much appreciate being told
 >>where and how this code is kludgey and could be improved. As I said, it 
seems to
 >>work, but I don't think it will win any prizes for beauty or being 
Pythonic. If
 >>asking for such a critique is over-imposing, I understand. (My aim in 
asking is
 >>to break bad habits before they become entrenched. Brutal criticism is 
happily
 >>accepted.)
 >>
 >
 > The fileinput module makes it easy to process lists of input files or
 > piped input through stdin.  That's usually better than prompting for
 > filenames in your program.

Thanks for the tip. I will look into that module closely. On quick
inspection though, its Library Reference entry ends with "Caveat: The
current implementation does not work for MS-DOS 8+3 filesystems.", which, I
expect, will matter to a Windows victim -- I mean user -- like myself.

I take it the point is that the in program prompt makes it harder to
abstract as a module for other programs to import?


 >>Right near the top, there is a comment where I have a question about how 
to do
 >>it better.
 >
 >
 > Use triple quotes for multi-line strings.  These can break the indent
 > rules.  I adjusted your code down below.

Thanks, I knew that was an option. What I meant by not breaking the
function's definition indentation was not just avoiding a syntax error, but
also not loosing the visual cue of the indent. For a smallish script like
the one I posted I guess it doesn't matter. But I was looking for a way to
print nice while keeping the visual indent for ease of code-scanning. (For
some reason, my eye recoils when I see out-dented text in a definition of a
conditional code block.) But now that I think about it, I could just assign
the string to a variable outside the function definition.

(I've snipped out all of my original code save the chunk relevant to the
point above.)


 > One other thing to note, Python now has an enumerate function which will
 > provide a counter as you iterate.  This allows you to write:
 >
 > for i,line in enumerate(sfile):
 >
 > and helps avoid errors where you forget to initialize the counter or
 > fail to increment the counter.

That is cool. As it happens, I forgot to increment the counter when I first
wrote it and spent a head-scratch moment or two being puzzled by the funny
output.

Thanks for the feedback!

And just before I sent this, I saw there are new replies. Thanks for those
too; I've not yet had a chance to look, but will.

Best,

Brian vdB



 >>
 >>-----
 >>import os.path
 >>
 >>def get_filename():
 >
 >        filename_prompt = '''What file would you like to process?
 > (Specify a full path if it is not in the current working directory)
 > '''
 >
 >>     f = raw_input(filename_prompt)
 >>     # This makes for ugly screen output. How can I left allign the output
 >>     # without breaking the function def's indetation?
 >>     return f