D
Doug Tolton
At my company we have a program that parses through certain types of
electronic files and stores the information in plain text. E-mail
poses an interesting problem for us, because most of the text tends to
be wrapped and doesn't contain hard returns. The specific web control
we use to display this text will simply show the text of the e-mail as
a single continuous line.
On friday I was asked to fix the text for these files so it would be
appropriately wrapped at a line width of 80 characters. Yesterday I
began writing the code to deal with this. I was at work until 5:15 am
today trying to solve all the little quirks of that type of parsing.
I finally got most of the kinks worked out, and ran it, however at
great personal cost (ie lost sleep).
Much to my dismay I was browsing this board and saw the post about
Summer Reading:
With a sinking feeling I opened the textwrap.py module and browsed
through it. After running several tests and playing with some of the
settings, this was *exactly* what I needed.
I've always enjoyed writing code. I particularly enjoy solving hard
problems, what I don't like is trying to solve them under immense
pressure from a client. Ultimately the problem itself was moderately
hard to solve, but the conditions made it even more difficult. I had
an inordinately large amount of text to deal with, so my test cycle
was ungodly slow.
Had I spent 30 minutes looking through the documentation, I could've
saved my self one helluva long night.
As much as I hate to be the example, it really is a wonderful
illustratration of why following the Unix / OSS development model is a
better way to go.
1. Check to see if someone has already written an app to do what you
want done.
2. Check to see if someone has written something that is close to what
you want done. If you can get the source code, modify it to do what
you need specifically.
3. Write it from scratch.
Instead of working my way down the list, I jumped straight to number
3. While that can be useful for an academic excercise, or when you
are going for a more rigorous approach, it's seldom useful when you
have a looming deadline.
Doug Tolton
electronic files and stores the information in plain text. E-mail
poses an interesting problem for us, because most of the text tends to
be wrapped and doesn't contain hard returns. The specific web control
we use to display this text will simply show the text of the e-mail as
a single continuous line.
On friday I was asked to fix the text for these files so it would be
appropriately wrapped at a line width of 80 characters. Yesterday I
began writing the code to deal with this. I was at work until 5:15 am
today trying to solve all the little quirks of that type of parsing.
I finally got most of the kinks worked out, and ran it, however at
great personal cost (ie lost sleep).
Much to my dismay I was browsing this board and saw the post about
Summer Reading:
With a sinking feeling I opened the textwrap.py module and browsed
through it. After running several tests and playing with some of the
settings, this was *exactly* what I needed.
I've always enjoyed writing code. I particularly enjoy solving hard
problems, what I don't like is trying to solve them under immense
pressure from a client. Ultimately the problem itself was moderately
hard to solve, but the conditions made it even more difficult. I had
an inordinately large amount of text to deal with, so my test cycle
was ungodly slow.
Had I spent 30 minutes looking through the documentation, I could've
saved my self one helluva long night.
As much as I hate to be the example, it really is a wonderful
illustratration of why following the Unix / OSS development model is a
better way to go.
1. Check to see if someone has already written an app to do what you
want done.
2. Check to see if someone has written something that is close to what
you want done. If you can get the source code, modify it to do what
you need specifically.
3. Write it from scratch.
Instead of working my way down the list, I jumped straight to number
3. While that can be useful for an academic excercise, or when you
are going for a more rigorous approach, it's seldom useful when you
have a looming deadline.
Doug Tolton