iterators (was: python-dev summary)

[Andrew Dalke]

Grant Griffin:
>However...
>
>I regret Python's increasing loss of status as "executable
>pseudo-code".  This proposal, as well as 2.0's "list comprehensions",
>seem to be making Python harder for the uninitiated to read.  (To be
>fair, though, as a "moderately-initiated" Pythoneer, I've recently
>warmed up to list comprehensions.)
>[more comments removed]

I admit to a "Me too!" here.

I work in computational biology and chemisty.  This means
I work with developers (people with a lot of programming
background and some science background), scientists (the
opposite) and people in various states in between (I'm a
physicist who became a developer).

I've pushed Python partially because it is a language
which developers enjoy *and* so do scientists.  I compare
it to Perl which developers enjoy but researchers don't.
(As a generality - there are exceptions.)  Another example
is Tcl, which developers often find tedious but researchers
use just fine.  (Mind you, I used Tcl in the pre-8.0 days.)

The goal of a researcher is to do science, and they will
put up with a lot to do it.  A computational scientist
will often learn a dozen different ad hoc scripting languages
needed by the various programs they use.  However, there
is a certain level of complexity beyond which few researchers
will learn.  In general, the more obvious the better, as with
Tcl.

On the other hand, developers will learn about all the
intricacies of a language, and attempt to use the appropriate
feature for a given task.  Sometimes a feature is used
for the shear elegance or novelity of a construct, at the
detriment of clarity.

For example, I'll bet list comprehensions will be a
problem when my clients start using Python 2.0.  It is
syntax driven and implicit, rather than using named
functions with an explicit loop.  That's why I plan to
use list comprehensions rarely, and only for a single
level of comprehension.

I see similar problems with ">>" and now with "k:v" iterators.
These all mean there will be multiple ways to do the same
task.  Especially worrying is that the best ways will
be the most obscure.

This reminds me of a story Gerald Weinberg tells about a
"possum burger" company where a consultant comes in and says
the company can save a large amount of money by reducing the
number of sesame seeds on the bun by 1, with no measureable
change in taste.  The problem is, enough unnoticable changes
do make a difference.  Eventually people will go elsewhere
for possum burgers.

Explicit is better, so in another branch of this thread
I elaborate on a suggestion for how to make explicit
iterators (via functions & classes in a new module).

                    Andrew Dalke
                    dalke at acm.org