Newbie Q on searching lists

[Terry Hancock]

On Saturday 23 November 2002 08:06 am, Kenny Tilton wrote:
> Terry Hancock wrote:
> > Did you mean this?
> > 
> > if thisCalculator in calculators:
> >         raise CircularDependency(thisCalculator)
> 
> sweet. thx. for the heads up on custom exceptions as well. I was faking 
> that bit (as you could tell <g>), just wanted to put up a more readable 
> example.

Actually "raise CircularDependency, thisCalculator" is also correct, although
perhaps slightly less clear about what is actually happening. It is in fact 
the old way to raise an  exception (when exceptions were just strings). The 
newer exceptions (Python 2.0+?) are classes.

I assumed of course, that you defined CircularDependency as an exception 
somewhere earlier in your code.

I was actually just trying to suggest using "in" since you seemed to be 
trying to find out only if thisCalculator was contained in calculators -- 
that being what the "in" operator is for.

Use .index() where it is in the sequence once you know it's there. This is a 
general pattern in Python -- find out *if* it's there, then get it.  As in:

d = {'spam':1, 'eggs':2}
if d.has_key('spam'):
    e = d['spam']

Why?

I think it's because generally if you're looking for something that isn't 
there, you've made a mistake.  So it makes sense to raise an exception. That 
way, Python warns you, making the bug very transparent.

If on the other hand, the existence of an item in a container is only 
possible, and not required, then you as the programmer ought to be thinking 
about that possibility when you code it. Thus, Python makes you say "I want 
to see if the item is there and then get it if it is" or (as the following 
idiom does) "I want to set it to the value of the item with a default of 
'ham'":

e = d.get('spam', default='ham')

Many other languages would try to do this thinking for you -- specifying a 
defined behavior in the language (such as returning None) if the item isn't 
there.  But that means you have to be constantly vigilant against hidden 
exceptional conditions propagating their way through your code (had it simply 
returned None, and you didn't think it could do that -- how much further down 
in your code would you have to look to find the place it actually failed?).
IMHO, that's "penny-wise and pound-foolish". Better to fail right away, and 
force you to think about the edge conditions now, while you're coding it.

Just as (good) GUIs are based on careful thought about the interface between 
the user and the software, Python is based on careful thought about the 
interface between the programmer and the code. I think that's the central 
insight behind its design.  (Speculating about the "Why is Python popular..." 
thread and the "thinking in python" idea).

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com