why won't slicing lists raise IndexError?

Rick Johnson rantingrickjohnson at gmail.com
Mon Dec 4 18:50:55 EST 2017


Chris Angelico wrote:
> <rantingrickjohnson at gmail.com> wrote:
> > Terry Reedy wrote:
> >
> > [...]
> >
> >> try:
> >>      item = seq[n]
> >> except IndexError
> >>      do_without_item()
> >> else:
> >>      process(item)
> >>
> >> item = seq[n:n+1]
> >> if item:
> >>      process(item)
> >> else:
> >>      do_without_item()
> >>
> >> Many prefer the second.
> >
> > And they'll prefer it even more when they realize the entire ELSE
> > clause of your latter example is superfluous.
> 
> ... how is it superfluous?

If the only purpose of an if/else logic structure is to
process an arbitrary value _only_ when that value is
"truthy", and futhermore, the else clause does nothing of
any significance (and in the example provided, appears to
be nothing but a placeholder for dead code) then why
bother writing the else clause in the first place?

I'm not questioning Terry's skills here. I'm merely pointing
out that there seems to be no justification for the else
clause in this example.

Indeed, there are valid instances when a decision making
process requires an explicit binary choice (aka: if/else),
but the provided example seems to be saying something more
like this:

# BEGIN CODE (Py2.x, Untested!) ##

if item:
    do_something_with(item)
else:
    import cons as cons
    try:
        try:
            h = get_handle_for_current_module()
        except NameError:
            import gvrs_backdoor
            h = gvrs_backdoor.force_connection(cons.CURRENT_MODULE)
        #
        # Assume we have a valid module handle here.
        #
        with h.request_connection(cons.PYTHON) as py:
            py.send_message(cons.EXIT_CONDITIONAL)
    except Exception as e:
        #
        # Alas, now we must wipe the sweat from our brow 
        # and accept our unavoidable fate. ':-(
        #
        # But first! We shall be good stewards and log 
        # this error message.
        #
        msg = e.message
        print msg[len(msg):]
        del msg
        #
        # Now: 1. 2.. 3... JUMP!
        #
        pass
        
## END CODE ##
            
Of course, we could have accomplished the same goal -- and
burned a few less processor cycles in the meantime -- by
omitting the superflouous else clause. 

But to each, his or her own, i suppose.




More information about the Python-list mailing list