The importance of using Library Functions

[Doug Tolton]

On Wed, 13 Aug 2003 02:26:18 GMT, Doug Tolton <dtolton at yahoo.com>
wrote:

>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:
>
>On Tue, 12 Aug 2003 06:57:05 GMT, "Raymond Hettinger"
><vze4rx4y at verizon.net> wrote:
>
>>Found in a pamphlet at a pre-school:
>>---------------------------------------
>>Reading improves vocabulary
>>Reading raises cultural literacy through shared knowledge
>>Reading develops writing skills
>>Reading opens the mind to new ways of understanding
>>Reading is fun
>>
>>
>>Accordingly, I suggest the following works of literature:
>>
>>   * heapq.py         (255 lines)
>>   * sets.py          (536 lines)
>>   * textwrap.py      (355 lines)
>>   * csv.py           (427 lines)
>
>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


Interestingly TextWrap choked on the text I'm running it against.  I'm
sure it's more an issue of complete craziness in these files than an
actual problem with TextWrap.

While it doesn't change the fact that I should have approached the
problem differently at the outset, it makes me happy to know that I
didn't waste all that time writing my code.

Doug Tolton