[Tutor] working code for adding line numbers -- request
for criticism
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:
>
>>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
More information about the Tutor
mailing list