[Tutor] working code for adding line numbers -- request
Brian van den Broek
bvande at po-box.mcgill.ca
Sat Apr 17 18:27:11 EDT 2004
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:
>>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
>>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)
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
>>so, no harm, as the exercise was useful, but I'd probably be better off
>>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
>>work, but I don't think it will win any prizes for beauty or being
>>asking for such a critique is over-imposing, I understand. (My aim in
>>to break bad habits before they become entrenched. Brutal criticism is
> 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
> 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
> 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
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.
> 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
More information about the Tutor