PEP 284, Integer for-loops

Steve Lamb grey at despair.dmiyu.org
Wed Mar 6 19:51:59 EST 2002


On Wed, 06 Mar 2002 16:21:31 -0800, David Eppstein <eppstein at ics.uci.edu>
wrote:
> Speak for yourself, please.  To Steve Lamb, range(foo,bar,baz) may be 
> clear but it is not to me.  

    PEBKAC?

> And please avoid the ad-hominems ("too lazy to learn the language"), it 
> doesn't contribute to rational debate.

    Then why is it you're so gung-ho to make the language more complex when
there are several ways to what you want already in the language?

    Fine, don't like range(n-1,-1,-1) and don't feel like taking the <60s to
look it up?  I give you:

foo = range(n-1,0)
foo.reverse()
for x in foo:
    do_whatcha_like(x)

    Still too obtuse for you?

x = bar
while x > n:
    do_whatcha_like(x)
    x = x-1

    Anyone else care to jump in and show a different method?

    The point stands, this PEP is a specific language nit for a specific case
which is easily solvable by SEVERAL general constructs already available in
the language.  It is very limiting (only allowing one stepping, apparently)
and would be used only in very specific cases.  IMHO those should be avoided
like the plague for while they might be useful in a very limited sense a slew
of said specific case constructs creates a language that is large, bloated and
difficult to read overall because you have to learn how dozens of different
special case constructs work instead of, heaven forbid, just read the code and
be able to grok the meaning out of a small set of generic constructs.
Furthermore specific constructs for specific cases also blow maintainability
out of the water.  Take the famous example from Perl.  

if () {}
unless () {}
statement if ()
statement unless ()

    Only one of them is maintainable; the first.  Sure, the other's look nice
and sometimes unless (foo) is easier to figure out than if (!foo) but the
point is in the last three cases one cannot easily add an else unless they
rewrite it to the former.

    You have different ways of approaching your problem as it is.  You can
build a set any way you choose before tossing it into either of available
generic constructs.  There is no compelling reason to add one more other than
to appease one person's "It's not clear to me."  That, sir, is NOT enough.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
    To email: Don't despair!   |  -- Lenny Nero, Strange Days
-------------------------------+---------------------------------------------



More information about the Python-list mailing list