Python rocks

George Sakkis george.sakkis at gmail.com
Sun Jun 3 12:18:10 EDT 2007


On Jun 2, 4:58 pm, a... at pythoncraft.com (Aahz) wrote:

> In article <1180807432.351720.123... at p47g2000hsd.googlegroups.com>,
> George Sakkis  <george.sak... at gmail.com> wrote:
>
>
>
> >I had probably stumbled on many/most of the common pitfalls usually
> >mentioned (e.g.http://www.ferg.org/projects/python_gotchas.html,
> >http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
> >picked them up easily after the first or second time. Off the top of
> >my head, two errors that keep coming back even years after are:
> >- Comparing instances of (semantically) incomparable types (http://
> >www.ibm.com/developerworks/library/l-python-elegance-1.html).
> >Thankfully this will be fixed in Py3k.
> >- Strings being iterable; unfortunately this will stay in Py3K.
>
> I'll repeat the comment I made on python-3000:
>
>     "...string iteration isn't about treating strings as sequences of
>     strings, it's about treating strings as sequences of characters.  The
>     fact that characters are also strings is the reason we have problems,
>     but characters are strings for other good reasons."

No, the reason we have problems is that far more often than not
strings are treated as atomic values, not sequences of smaller strings
or characters. A classic example is flatten(), where most people are
surprised if flatten([1, (3.14, 'hello')]) returns [1, 3.14, 'h', 'e',
'l', 'l', 'o'].

> Thing is, the fact that you can e.g. slice strings just like other
> sequence types creates the consequence that you can also iterate over
> strings -- moreover, some of us actually do iterate over strings (though
> of course we could if necessary create lists/tuples of characters).  In
> the grand scheme of things, I rarely see people running into problems
> with iterating over strings.

One class of problems is functions such as flatten() that expect "a
collection or an atom", with strings being typically considered
atomic. A second common pitfall are functions that expect file-like
objects but are given file names instead:

def process_file(input_file):
    for line in input_file:
        do_stuff(line)


process_file('/home/george/.bashrc')  # oops

I now try to remember to write such functions as:

def process_file(input_file):
    if isinstance(input_file, basestring):
        input_file = open(input_file)
    for line in input_file:
        ...

It's not a huge impediment by any means but it's certainly a gotcha.

George




More information about the Python-list mailing list